Re: [leaf-devel] proposing a timeframe and features for 5.0-alpha2
Le 26 déc. 2012 à 00:01, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi; sorry for the delay - I started the discussion and then went offline :( Am 21.12.2012 10:21, schrieb Yves Blusseau: Le 19 déc. 2012 à 17:46, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi Gents; I'd like to make a proposal for the timeframe and features of the second alpha version of 5.0. First of all, I think it should still be an alpha version - so neither the kernel nor the uClibc are fixed. Also the major goal for 5.0 to support other cpu architectures misses at least one image/example. We saw over 100 downloads of alpha1 and received no complaints so far, so I consider for X86_32 even an alpha1 version was not bad. Along with usual Package updates and fixes, the new features for the second alpha could be a X86_64 image and to enable zram support at least, and eventually offering signed packages. As far as I'm aware a X86_64 version currently needs - a patch for vsftpd - a solution for the uClibc loader (lib/ld-uClibc-0.9.33.2.so vs lib/ld64-uClibc-0.9.33.2.so - and images (AFAIR it worked without changes) About the uClibc shared library, i've already start to discuss about this with Andrew. Look at the messages with x86_64 toolchain subject. Actually we are 2 solutions: * Patch the toolchain so the library will always be: /lib/ld-uClibc.so * Add a variable and put the right name for every toolchains Ouch, I missed that part in the thread, just read the stuff about the compilation with gcc. Reread, and my vote goes for option 2. Option 2 is: use a variable in every toolchain ? Andrew was talking also to create symlinks. About zram support, I've lost track about it's status. I know some changes has been made in master (like swap support in the kernel), others seems to be merged into next branch (like changes to conf/images/common/leaf.cfg) - don't know what other changes ended in which repository..., and finally it lacks any documentation how to enable and to make use of it. The zram support is in the topic branch: buc5-zram-support This branch as been merged in next but not in master. If we decided to integrate it, we only have to merge the topic branch into master. For the configuration there are a new variable: zswap_size that can be defined in leaf.cfg. The values can be: -1 = disabled 0 = auto other = size of sram swap partition Default is -1, but for our images i fixed it to 0 (in conf/image/common/config.cfg) I'd like to integrate it now - if disabled it won't cause any harm, when enabling it, it (hopefully) just works and we'll have the chance to get feedback. If we agree, can you pls merge the topic branch into master? Branch buc5-zram-support merged info master. next branch was reset to master because now it's the same. Branch buc5-zram-support deleted. I'll try to take of the documentation. Go ahead :D Regards, Yves -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] proposing a timeframe and features for 5.0-alpha2
Am 27.12.2012 15:24, schrieb Yves Blusseau: Le 26 déc. 2012 à 00:01, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi; sorry for the delay - I started the discussion and then went offline :( Am 21.12.2012 10:21, schrieb Yves Blusseau: Le 19 déc. 2012 à 17:46, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi Gents; I'd like to make a proposal for the timeframe and features of the second alpha version of 5.0. First of all, I think it should still be an alpha version - so neither the kernel nor the uClibc are fixed. Also the major goal for 5.0 to support other cpu architectures misses at least one image/example. We saw over 100 downloads of alpha1 and received no complaints so far, so I consider for X86_32 even an alpha1 version was not bad. Along with usual Package updates and fixes, the new features for the second alpha could be a X86_64 image and to enable zram support at least, and eventually offering signed packages. As far as I'm aware a X86_64 version currently needs - a patch for vsftpd - a solution for the uClibc loader (lib/ld-uClibc-0.9.33.2.so vs lib/ld64-uClibc-0.9.33.2.so - and images (AFAIR it worked without changes) About the uClibc shared library, i've already start to discuss about this with Andrew. Look at the messages with x86_64 toolchain subject. Actually we are 2 solutions: * Patch the toolchain so the library will always be: /lib/ld-uClibc.so * Add a variable and put the right name for every toolchains Ouch, I missed that part in the thread, just read the stuff about the compilation with gcc. Reread, and my vote goes for option 2. Option 2 is: use a variable in every toolchain ? I thought this pointed to to your proposal about including $(toolchain).files in initrd/buildtool.cfg. Though it does not work yet, and it has a slight drawback, that we need a file which defines the loader for each architecture, even if only the X86_64-bit version is known to require that change, I prefer this option over patching uClibc... Andrew was talking also to create symlinks. Haven't read that, and no code yet. In either way, I hope we'll find a good solution, cause that's the only remaing task IMHO for a second alpha version of 5.x. About zram support, I've lost track about it's status. I know some changes has been made in master (like swap support in the kernel), others seems to be merged into next branch (like changes to conf/images/common/leaf.cfg) - don't know what other changes ended in which repository..., and finally it lacks any documentation how to enable and to make use of it. The zram support is in the topic branch: buc5-zram-support This branch as been merged in next but not in master. If we decided to integrate it, we only have to merge the topic branch into master. For the configuration there are a new variable: zswap_size that can be defined in leaf.cfg. The values can be: -1 = disabled 0 = auto other = size of sram swap partition Default is -1, but for our images i fixed it to 0 (in conf/image/common/config.cfg) I'd like to integrate it now - if disabled it won't cause any harm, when enabling it, it (hopefully) just works and we'll have the chance to get feedback. If we agree, can you pls merge the topic branch into master? Branch buc5-zram-support merged info master. next branch was reset to master because now it's the same. Branch buc5-zram-support deleted. thx. I'll try to take of the documentation. Go ahead :D ok :) kp -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] proposing a timeframe and features for 5.0-alpha2
Am 27.12.2012 20:35, schrieb Yves Blusseau: Le 27 déc. 2012 à 19:06, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Am 27.12.2012 15:24, schrieb Yves Blusseau: Le 26 déc. 2012 à 00:01, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi; sorry for the delay - I started the discussion and then went offline :( Am 21.12.2012 10:21, schrieb Yves Blusseau: Le 19 déc. 2012 à 17:46, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi Gents; I'd like to make a proposal for the timeframe and features of the second alpha version of 5.0. First of all, I think it should still be an alpha version - so neither the kernel nor the uClibc are fixed. Also the major goal for 5.0 to support other cpu architectures misses at least one image/example. We saw over 100 downloads of alpha1 and received no complaints so far, so I consider for X86_32 even an alpha1 version was not bad. Along with usual Package updates and fixes, the new features for the second alpha could be a X86_64 image and to enable zram support at least, and eventually offering signed packages. As far as I'm aware a X86_64 version currently needs - a patch for vsftpd - a solution for the uClibc loader (lib/ld-uClibc-0.9.33.2.so vs lib/ld64-uClibc-0.9.33.2.so - and images (AFAIR it worked without changes) About the uClibc shared library, i've already start to discuss about this with Andrew. Look at the messages with x86_64 toolchain subject. Actually we are 2 solutions: * Patch the toolchain so the library will always be: /lib/ld-uClibc.so * Add a variable and put the right name for every toolchains Ouch, I missed that part in the thread, just read the stuff about the compilation with gcc. Reread, and my vote goes for option 2. Option 2 is: use a variable in every toolchain ? I thought this pointed to to your proposal about including $(toolchain).files in initrd/buildtool.cfg. Though it does not work yet, and it has a slight drawback, that we need a file which defines the loader for each architecture, even if only the X86_64-bit version is known to require that change, I prefer this option over patching uClibc… I have committed a simple solution (commit f0fac75c) Hi Yves, just give it a *very quick* test, see below. Haven't checked if the initrd built works. kp Generating package initrd Use of uninitialized value $type in uc at ./buildpacket.pl line 1198. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in concatenation (.) or string at /usr/lib/perl/5.14/File/Spec/Unix.pm line 50. Use of uninitialized value $file in pattern match (m//) at /usr/lib/perl/5.14/File/Spec/Unix.pm line 97. Use of uninitialized value $file in
Re: [leaf-devel] proposing a timeframe and features for 5.0-alpha2
Am 27.12.2012 20:56, schrieb KP Kirchdoerfer: Am 27.12.2012 20:35, schrieb Yves Blusseau: Le 27 déc. 2012 à 19:06, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Am 27.12.2012 15:24, schrieb Yves Blusseau: Le 26 déc. 2012 à 00:01, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi; sorry for the delay - I started the discussion and then went offline :( Am 21.12.2012 10:21, schrieb Yves Blusseau: Le 19 déc. 2012 à 17:46, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi Gents; I'd like to make a proposal for the timeframe and features of the second alpha version of 5.0. First of all, I think it should still be an alpha version - so neither the kernel nor the uClibc are fixed. Also the major goal for 5.0 to support other cpu architectures misses at least one image/example. We saw over 100 downloads of alpha1 and received no complaints so far, so I consider for X86_32 even an alpha1 version was not bad. Along with usual Package updates and fixes, the new features for the second alpha could be a X86_64 image and to enable zram support at least, and eventually offering signed packages. As far as I'm aware a X86_64 version currently needs - a patch for vsftpd - a solution for the uClibc loader (lib/ld-uClibc-0.9.33.2.so vs lib/ld64-uClibc-0.9.33.2.so - and images (AFAIR it worked without changes) About the uClibc shared library, i've already start to discuss about this with Andrew. Look at the messages with x86_64 toolchain subject. Actually we are 2 solutions: * Patch the toolchain so the library will always be: /lib/ld-uClibc.so * Add a variable and put the right name for every toolchains Ouch, I missed that part in the thread, just read the stuff about the compilation with gcc. Reread, and my vote goes for option 2. Option 2 is: use a variable in every toolchain ? I thought this pointed to to your proposal about including $(toolchain).files in initrd/buildtool.cfg. Though it does not work yet, and it has a slight drawback, that we need a file which defines the loader for each architecture, even if only the X86_64-bit version is known to require that change, I prefer this option over patching uClibc… I have committed a simple solution (commit f0fac75c) Hi Yves, just give it a *very quick* test, see below. Haven't checked if the initrd built works. Sorry, just replaced buildtool.pl and overlooked initrd changes... will do another test kp -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] proposing a timeframe and features for 5.0-alpha2
Am 27.12.2012 20:59, schrieb KP Kirchdoerfer: Am 27.12.2012 20:56, schrieb KP Kirchdoerfer: Am 27.12.2012 20:35, schrieb Yves Blusseau: Le 27 déc. 2012 à 19:06, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Am 27.12.2012 15:24, schrieb Yves Blusseau: Le 26 déc. 2012 à 00:01, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi; sorry for the delay - I started the discussion and then went offline :( Am 21.12.2012 10:21, schrieb Yves Blusseau: Le 19 déc. 2012 à 17:46, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi Gents; I'd like to make a proposal for the timeframe and features of the second alpha version of 5.0. First of all, I think it should still be an alpha version - so neither the kernel nor the uClibc are fixed. Also the major goal for 5.0 to support other cpu architectures misses at least one image/example. We saw over 100 downloads of alpha1 and received no complaints so far, so I consider for X86_32 even an alpha1 version was not bad. Along with usual Package updates and fixes, the new features for the second alpha could be a X86_64 image and to enable zram support at least, and eventually offering signed packages. As far as I'm aware a X86_64 version currently needs - a patch for vsftpd - a solution for the uClibc loader (lib/ld-uClibc-0.9.33.2.so vs lib/ld64-uClibc-0.9.33.2.so - and images (AFAIR it worked without changes) About the uClibc shared library, i've already start to discuss about this with Andrew. Look at the messages with x86_64 toolchain subject. Actually we are 2 solutions: * Patch the toolchain so the library will always be: /lib/ld-uClibc.so * Add a variable and put the right name for every toolchains Ouch, I missed that part in the thread, just read the stuff about the compilation with gcc. Reread, and my vote goes for option 2. Option 2 is: use a variable in every toolchain ? I thought this pointed to to your proposal about including $(toolchain).files in initrd/buildtool.cfg. Though it does not work yet, and it has a slight drawback, that we need a file which defines the loader for each architecture, even if only the X86_64-bit version is known to require that change, I prefer this option over patching uClibc… I have committed a simple solution (commit f0fac75c) Hi Yves, just give it a *very quick* test, see below. Haven't checked if the initrd built works. Sorry, just replaced buildtool.pl and overlooked initrd changes... will do another test Hi Yves; now it's a lot better := no errors. Great! I'll rebuild everything from scratch and test via qemu, but this will take some time. kp -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] proposing a timeframe and features for 5.0-alpha2
Hi; sorry for the delay - I started the discussion and then went offline :( Am 21.12.2012 10:21, schrieb Yves Blusseau: Le 19 déc. 2012 à 17:46, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi Gents; I'd like to make a proposal for the timeframe and features of the second alpha version of 5.0. First of all, I think it should still be an alpha version - so neither the kernel nor the uClibc are fixed. Also the major goal for 5.0 to support other cpu architectures misses at least one image/example. We saw over 100 downloads of alpha1 and received no complaints so far, so I consider for X86_32 even an alpha1 version was not bad. Along with usual Package updates and fixes, the new features for the second alpha could be a X86_64 image and to enable zram support at least, and eventually offering signed packages. As far as I'm aware a X86_64 version currently needs - a patch for vsftpd - a solution for the uClibc loader (lib/ld-uClibc-0.9.33.2.so vs lib/ld64-uClibc-0.9.33.2.so - and images (AFAIR it worked without changes) About the uClibc shared library, i've already start to discuss about this with Andrew. Look at the messages with x86_64 toolchain subject. Actually we are 2 solutions: * Patch the toolchain so the library will always be: /lib/ld-uClibc.so * Add a variable and put the right name for every toolchains Ouch, I missed that part in the thread, just read the stuff about the compilation with gcc. Reread, and my vote goes for option 2. About zram support, I've lost track about it's status. I know some changes has been made in master (like swap support in the kernel), others seems to be merged into next branch (like changes to conf/images/common/leaf.cfg) - don't know what other changes ended in which repository..., and finally it lacks any documentation how to enable and to make use of it. The zram support is in the topic branch: buc5-zram-support This branch as been merged in next but not in master. If we decided to integrate it, we only have to merge the topic branch into master. For the configuration there are a new variable: zswap_size that can be defined in leaf.cfg. The values can be: -1 = disabled 0 = auto other = size of sram swap partition Default is -1, but for our images i fixed it to 0 (in conf/image/common/config.cfg) I'd like to integrate it now - if disabled it won't cause any harm, when enabling it, it (hopefully) just works and we'll have the chance to get feedback. If we agree, can you pls merge the topic branch into master? I'll try to take of the documentation. kp -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] proposing a timeframe and features for 5.0-alpha2
Le 19 déc. 2012 à 17:46, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Hi Gents; I'd like to make a proposal for the timeframe and features of the second alpha version of 5.0. First of all, I think it should still be an alpha version - so neither the kernel nor the uClibc are fixed. Also the major goal for 5.0 to support other cpu architectures misses at least one image/example. We saw over 100 downloads of alpha1 and received no complaints so far, so I consider for X86_32 even an alpha1 version was not bad. Along with usual Package updates and fixes, the new features for the second alpha could be a X86_64 image and to enable zram support at least, and eventually offering signed packages. As far as I'm aware a X86_64 version currently needs - a patch for vsftpd - a solution for the uClibc loader (lib/ld-uClibc-0.9.33.2.so vs lib/ld64-uClibc-0.9.33.2.so - and images (AFAIR it worked without changes) About the uClibc shared library, i've already start to discuss about this with Andrew. Look at the messages with x86_64 toolchain subject. Actually we are 2 solutions: * Patch the toolchain so the library will always be: /lib/ld-uClibc.so * Add a variable and put the right name for every toolchains About zram support, I've lost track about it's status. I know some changes has been made in master (like swap support in the kernel), others seems to be merged into next branch (like changes to conf/images/common/leaf.cfg) - don't know what other changes ended in which repository..., and finally it lacks any documentation how to enable and to make use of it. The zram support is in the topic branch: buc5-zram-support This branch as been merged in next but not in master. If we decided to integrate it, we only have to merge the topic branch into master. For the configuration there are a new variable: zswap_size that can be defined in leaf.cfg. The values can be: -1 = disabled 0 = auto other = size of sram swap partition Default is -1, but for our images i fixed it to 0 (in conf/image/common/config.cfg) Regards, Yves -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
