diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20130104')
8 files changed, 78 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment-0001.html new file mode 100644 index 000000000..8ce2835ed --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment-0001.html @@ -0,0 +1,8 @@ +<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>I've already posted this to the Mageia forum, but doktor5000 suggested to also post this to the mailing list.</div><div><br></div><div>I'd like to ask if it would make sense for Mageia to automatically test generated RPM packages. The idea isn't new. Ubuntu is using regression tests with python-unit for a lot of packages in their distribution: <a href="https://wiki.ubuntu.com/MeetingLogs/devweek0909/RegressionTests">https://wiki.ubuntu.com/MeetingLogs/devweek0909/RegressionTests</a></div> +<div><br></div><div>I think that using automated regession tests would make the job of QA a lot easier. Failures within packages would surface much faster and a lot of manual checking could be avoided. Don't get me wrong. Every package that would pass the regression tests should still be checked by a human. ;)</div> +<div><br></div><div>The following scenario could be used for this. After the package hast been generated, the RPM (or job) is passed to the regession test server. This server spawns a new virtual machine with the Mageia version the package should be checked on. When the machine is booted, the package is installed with all the needed dependencies and the tests are executed. If everyting went smooth, the package might be checked again by QA manually. If one or more tests failed, there is something wrong with package, although the package generation worked, and the maintainer/developer might want to take a look at it again.</div> +<div><br></div><div>To setup this up a combination of hudson (<a href="http://hudson-ci.org">hudson-ci.org</a>) and vagrant (<a href="http://vagrantup.com">vagrantup.com</a>) could be used. vagrant allows to use VirtualBox to boot serveral VM instances from base images that are thrown away after everything is done. This way multiple versions of Mageia could be tested on one well equipped server. One drawback with VirtualBox would be the missing ARM support.</div> +<div><br></div><div>Let's use something like a JSON lib for Python as an example. The package generation was successful. But Python is a highly dynamic language, so some submodule is missing due to a wrong install path, although "import json-xy" of the main module works flawlessly. Without further testing this will only surface when a poor developer uses the submodule or when a second package that depends on that submodule is tested by QA and shows errors or misbehaviours.</div> +<div>Second example, same lib. The JSON lib usually ships with a handy executable to lint check JSON files, but upstream decided to change that. Due to an error in the upstream repo, the executable script file is still there but it's empty or there is gibberish in it. There is no more lint checking possible with this executable. Automatic testing would show this very fast and without someone sitting there, pasting some JSON into a file to feed the executable with it.</div> +<div><br></div><div>Testing UI would be an other story, but I guess you get the idea. ;-)</div><div><br></div><div>That do you think about that? I think it would enhance the quality on Mageia in the long run and take some work from QA to find the really tricky bugs.</div> +<div><br></div><div>Regards,</div><div><br></div><div>Jochen</div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment.html b/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment.html new file mode 100644 index 000000000..8ce2835ed --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/182edc02/attachment.html @@ -0,0 +1,8 @@ +<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>I've already posted this to the Mageia forum, but doktor5000 suggested to also post this to the mailing list.</div><div><br></div><div>I'd like to ask if it would make sense for Mageia to automatically test generated RPM packages. The idea isn't new. Ubuntu is using regression tests with python-unit for a lot of packages in their distribution: <a href="https://wiki.ubuntu.com/MeetingLogs/devweek0909/RegressionTests">https://wiki.ubuntu.com/MeetingLogs/devweek0909/RegressionTests</a></div> +<div><br></div><div>I think that using automated regession tests would make the job of QA a lot easier. Failures within packages would surface much faster and a lot of manual checking could be avoided. Don't get me wrong. Every package that would pass the regression tests should still be checked by a human. ;)</div> +<div><br></div><div>The following scenario could be used for this. After the package hast been generated, the RPM (or job) is passed to the regession test server. This server spawns a new virtual machine with the Mageia version the package should be checked on. When the machine is booted, the package is installed with all the needed dependencies and the tests are executed. If everyting went smooth, the package might be checked again by QA manually. If one or more tests failed, there is something wrong with package, although the package generation worked, and the maintainer/developer might want to take a look at it again.</div> +<div><br></div><div>To setup this up a combination of hudson (<a href="http://hudson-ci.org">hudson-ci.org</a>) and vagrant (<a href="http://vagrantup.com">vagrantup.com</a>) could be used. vagrant allows to use VirtualBox to boot serveral VM instances from base images that are thrown away after everything is done. This way multiple versions of Mageia could be tested on one well equipped server. One drawback with VirtualBox would be the missing ARM support.</div> +<div><br></div><div>Let's use something like a JSON lib for Python as an example. The package generation was successful. But Python is a highly dynamic language, so some submodule is missing due to a wrong install path, although "import json-xy" of the main module works flawlessly. Without further testing this will only surface when a poor developer uses the submodule or when a second package that depends on that submodule is tested by QA and shows errors or misbehaviours.</div> +<div>Second example, same lib. The JSON lib usually ships with a handy executable to lint check JSON files, but upstream decided to change that. Due to an error in the upstream repo, the executable script file is still there but it's empty or there is gibberish in it. There is no more lint checking possible with this executable. Automatic testing would show this very fast and without someone sitting there, pasting some JSON into a file to feed the executable with it.</div> +<div><br></div><div>Testing UI would be an other story, but I guess you get the idea. ;-)</div><div><br></div><div>That do you think about that? I think it would enhance the quality on Mageia in the long run and take some work from QA to find the really tricky bugs.</div> +<div><br></div><div>Regards,</div><div><br></div><div>Jochen</div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130104/92370db3/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130104/92370db3/attachment-0001.html new file mode 100644 index 000000000..513fb1e4c --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/92370db3/attachment-0001.html @@ -0,0 +1 @@ +Hi,<br><br>Has anyone got Mageia 2 or Mageia 3 beta running on Amazon EC2?<br><br>I have been having a go, but not quite got there yet, so thought I'd ask if anyone has already done it?<br><br>Glen<br> diff --git a/zarb-ml/mageia-dev/attachments/20130104/92370db3/attachment.html b/zarb-ml/mageia-dev/attachments/20130104/92370db3/attachment.html new file mode 100644 index 000000000..513fb1e4c --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/92370db3/attachment.html @@ -0,0 +1 @@ +Hi,<br><br>Has anyone got Mageia 2 or Mageia 3 beta running on Amazon EC2?<br><br>I have been having a go, but not quite got there yet, so thought I'd ask if anyone has already done it?<br><br>Glen<br> diff --git a/zarb-ml/mageia-dev/attachments/20130104/9b041514/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130104/9b041514/attachment-0001.html new file mode 100644 index 000000000..7ef08e5a7 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/9b041514/attachment-0001.html @@ -0,0 +1,4 @@ +<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/1/4 Guillaume Rousse <span dir="ltr"><<a href="mailto:guillomovitch@gmail.com" target="_blank">guillomovitch@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +We already run existing tests suite during package build... Running them again on a different host would just change the execution environment to use runtime dependencies instead of build time dependencies. I don't know if the potential results are worth the additional infrastructure needed.</blockquote> +</div><br></div><div class="gmail_extra" style>I was under the impression, that only some kind of lint checking of the RPM was performed. I'm talking about checking the functionality of the packaged software. Are you already doing that? What kind of tests are performed during packaging?</div> +</div> diff --git a/zarb-ml/mageia-dev/attachments/20130104/9b041514/attachment.html b/zarb-ml/mageia-dev/attachments/20130104/9b041514/attachment.html new file mode 100644 index 000000000..7ef08e5a7 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/9b041514/attachment.html @@ -0,0 +1,4 @@ +<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/1/4 Guillaume Rousse <span dir="ltr"><<a href="mailto:guillomovitch@gmail.com" target="_blank">guillomovitch@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +We already run existing tests suite during package build... Running them again on a different host would just change the execution environment to use runtime dependencies instead of build time dependencies. I don't know if the potential results are worth the additional infrastructure needed.</blockquote> +</div><br></div><div class="gmail_extra" style>I was under the impression, that only some kind of lint checking of the RPM was performed. I'm talking about checking the functionality of the packaged software. Are you already doing that? What kind of tests are performed during packaging?</div> +</div> diff --git a/zarb-ml/mageia-dev/attachments/20130104/a3bcfb67/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130104/a3bcfb67/attachment-0001.html new file mode 100644 index 000000000..b29367b85 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/a3bcfb67/attachment-0001.html @@ -0,0 +1,26 @@ +Hi Thomas,<br><br><div class="gmail_quote">On 4 January 2013 04:41, Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@mageia.org" target="_blank">tmb@mageia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Glen Ogilvie skrev 3.1.2013 13:10:<br> +<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Hi,<br> +<br> +Has anyone got Mageia 2 or Mageia 3 beta running on Amazon EC2?<br> +<br> +I have been having a go, but not quite got there yet, so thought I'd ask<br> +if anyone has already done it?<br> +</blockquote> +<br> +There was someone on irc testing it and had some progress...<br> +I don't know if he finished his tests.<br> +<br> +One thing... you need kernel-server-3.4.24-1 from 2/updates_testing<br> +to get it to boot (kernel image gz kompressed)<br></blockquote><div><br>Thank you fro the tip about using kernel-server-3.4.24-1.<br>After switching to this kernel, and rebuilding initrd, with the command:<br>mkinitrd-mkinitrd --with=xen-blkfront --with=xennet --with=xen-netfront initrd-3.4.24-server-2.mga2.img 3.4.24-server-2.mga2<br> +<br>It worked on Amazon EC2 and I have a nice Amanzon EC2 Mageia2 box. I'll create a clean AMI for others to use in the next few weeks! I released a Mandriva 2011 public AMI about a year ago.<br><br>It went much better than my attempt with 3.3.8-server-2.mga2, which complained about the compression format.<br> +I see in the change log, you have switched it back to gzip. <br><br>Searching for the gzip signature, using<br> od -A d -t x1 vmlinuz-3.3.8-server-2.mga2 | grep '1f 8b 08 00' does not find it, for 3.3.8, but searching for the xz sig, using<br> +od -A d -t x1 vmlinuz-3.3.8-server-2.mga2 | grep -i 'fd 37 7a 58 5a 00', return a match. <br><br>I found what is a little bit of a trap for people... funny now I think about it. <br><br>the output from running file vmlinuz*<br> +<br>vmlinuz-3.4.24-server-2.mga2: + Linux kernel x86 boot executable bzImage, version 3.4.24-server-2.mga2 +(<a href="mailto:iurt@ecosse.mageia.org">iurt@ecosse.mageia.org</a>) #1 SMP Tue Dec 18, RO-rootFS, swap_dev 0x3, +Normal VGA<br>vmlinuz-3.3.8-server-2.mga2: Linux kernel x86 boot +executable bzImage, version 3.3.8-server-2.mga2 (<a href="mailto:iurt@jonund.mageia.org">iurt@jonund.mageia.org</a>) + #1 SMP Mon Jul 30 , RO-rootFS, swap_dev 0x2, Normal VGA<br><br>It is easy to assume that bzImage mean's bzip.. but it does not.. it means big zimage. the actual compression type is not displayed using the file command.<br> +<br>I wonder if a patch to the file command to also output the compression type for kernel images, might be a good idea?<br><br>Regards<br>Glen Ogilvie<br></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130104/a3bcfb67/attachment.html b/zarb-ml/mageia-dev/attachments/20130104/a3bcfb67/attachment.html new file mode 100644 index 000000000..b29367b85 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130104/a3bcfb67/attachment.html @@ -0,0 +1,26 @@ +Hi Thomas,<br><br><div class="gmail_quote">On 4 January 2013 04:41, Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@mageia.org" target="_blank">tmb@mageia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Glen Ogilvie skrev 3.1.2013 13:10:<br> +<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Hi,<br> +<br> +Has anyone got Mageia 2 or Mageia 3 beta running on Amazon EC2?<br> +<br> +I have been having a go, but not quite got there yet, so thought I'd ask<br> +if anyone has already done it?<br> +</blockquote> +<br> +There was someone on irc testing it and had some progress...<br> +I don't know if he finished his tests.<br> +<br> +One thing... you need kernel-server-3.4.24-1 from 2/updates_testing<br> +to get it to boot (kernel image gz kompressed)<br></blockquote><div><br>Thank you fro the tip about using kernel-server-3.4.24-1.<br>After switching to this kernel, and rebuilding initrd, with the command:<br>mkinitrd-mkinitrd --with=xen-blkfront --with=xennet --with=xen-netfront initrd-3.4.24-server-2.mga2.img 3.4.24-server-2.mga2<br> +<br>It worked on Amazon EC2 and I have a nice Amanzon EC2 Mageia2 box. I'll create a clean AMI for others to use in the next few weeks! I released a Mandriva 2011 public AMI about a year ago.<br><br>It went much better than my attempt with 3.3.8-server-2.mga2, which complained about the compression format.<br> +I see in the change log, you have switched it back to gzip. <br><br>Searching for the gzip signature, using<br> od -A d -t x1 vmlinuz-3.3.8-server-2.mga2 | grep '1f 8b 08 00' does not find it, for 3.3.8, but searching for the xz sig, using<br> +od -A d -t x1 vmlinuz-3.3.8-server-2.mga2 | grep -i 'fd 37 7a 58 5a 00', return a match. <br><br>I found what is a little bit of a trap for people... funny now I think about it. <br><br>the output from running file vmlinuz*<br> +<br>vmlinuz-3.4.24-server-2.mga2: + Linux kernel x86 boot executable bzImage, version 3.4.24-server-2.mga2 +(<a href="mailto:iurt@ecosse.mageia.org">iurt@ecosse.mageia.org</a>) #1 SMP Tue Dec 18, RO-rootFS, swap_dev 0x3, +Normal VGA<br>vmlinuz-3.3.8-server-2.mga2: Linux kernel x86 boot +executable bzImage, version 3.3.8-server-2.mga2 (<a href="mailto:iurt@jonund.mageia.org">iurt@jonund.mageia.org</a>) + #1 SMP Mon Jul 30 , RO-rootFS, swap_dev 0x2, Normal VGA<br><br>It is easy to assume that bzImage mean's bzip.. but it does not.. it means big zimage. the actual compression type is not displayed using the file command.<br> +<br>I wonder if a patch to the file command to also output the compression type for kernel images, might be a good idea?<br><br>Regards<br>Glen Ogilvie<br></div></div> |