It works! I might have to swallow these words again later, but for now - it works! The submit request that I submitted to openSUSE:12.2:ARM:Contrib:Cubox was accepted - meaning that at some stage in the hopefully near future, the official openSUSE CuBox image will be updated to the one generated from the updated JeOS-cubox project.
What do I mean when I say it works? Well, obviously, there is no graphic support whatsoever - but you knew that anyway (on the upside, Bill Merriam is looking into this currently). If you generate a raw image from the openSUSE:12.2:ARM:Contrib:Cubox JeOS project (see my fourth post on openSUSE on CuBox to see how) and dd it onto a mini SD card, then it will boot without manual intervention. That doesn't mean you won't need a serial connection - you will, because the first thing you will have to do is use yast2-firstboot to configure the system (language, keyboard, timezone, root password etc). But you won't need workarounds like those described in my second post to get the kernel to boot.
After booting into yast2-firstboot, you configure the system. After the first reboot a different initrd is used than the one on the SD card. There was a bug here (in the uboot-setup.tgz) but that has now been fixed. What this means is that the first reboot now also works and gets you into a working openSUSE 12.2 system.
Once you are in the system, you can install additional software using zypper. For example, I needed the "screen" package - so I searched for it using zypper search screen. Then I installed it with zypper install screen. Worked fine. If you use YaST for system administration, you can install some useful additional modules like yast2-http-server, yast2-samba-server, yast2-runlevel. See what YaST modules are available with zypper search yast*.
If you meet bugs, which I hope you will (so we can fix them), I'm not sure where to report them yet. Probably on the Novell Bugzilla - but if you have a bug and you don't know what to do, I'd suggest you mention it on the #opensuse-arm irc channel on Freenode.
Have fun with openSUSE 12.2 on CuBox!
Montag, 3. Dezember 2012
Freitag, 30. November 2012
Making yast2-ncurses look better when using through screen
In openSUSE on CuBox (Day 5) I posted a screenshot of how yast looks terrible when used in ncurses mode over the serial connection (i.e. when you connect to e.g. the CuBox using screen /dev/ttyUSB0 115200). Here is that screenshot again.
As you can see, the background is really messed up. Things get much worse if there is any "movement" involved - for example progress bars.
I think I have found a solution - or at least a workaround. Alex Graf got me thinking that the problem is more than likely that yast in ncurses mode just can't deal with the $TERM that is set when coming through the serial connection. I researched this a little more.
When coming over a serial connection
echo $TERM
told me "linux".
When coming over SSH
echo $TERM
told me "xterm"
Now, that probably isn't altogether incorrect. Alex Graf and Juergen Weigert got me thinking that maybe the screen/ncurses combination just didn't support color in "linux" or "xterm" $TERM modes. I tried using TERM=vt100, TERM=vt200 and TERM=vt500 (as well as the color modes TERM=screen256-color, TERM=vt200-color) but that made things worse, in my opinion. What happened was that YaST was displayed in black and white with no highlighting to show which entry was selected. YaST became pretty much impossible to use.
It turned out that there is an informative page on the openSUSE wiki which deals with YaST Tips and Tricks. There I saw the information "The default setting of the YaST ncurses UI is that the init routine detects the terminal type and automatically chooses the appropriate color theme." However, then I saw the hint:
Change the line Y2NCURSES_COLOR_THEME in the file /etc/sysconfig/yast2 from:
Y2NCURSES_COLOR_THEME=""
to
Y2NCURSES_COLOR_THEME="linux"
and also change:
TERM=screen; export TERM
For me, I then got an acceptable YaST. This is probably a bit of a hacky workaround, but maybe it could help somebody in the know identify the real problem and fix it properly.
That's all for now folks! Here's a screenshot of YaST in ncurses mode on the CuBox, over the serial connection...
I think I have found a solution - or at least a workaround. Alex Graf got me thinking that the problem is more than likely that yast in ncurses mode just can't deal with the $TERM that is set when coming through the serial connection. I researched this a little more.
When coming over a serial connection
echo $TERM
told me "linux".
When coming over SSH
echo $TERM
told me "xterm"
Now, that probably isn't altogether incorrect. Alex Graf and Juergen Weigert got me thinking that maybe the screen/ncurses combination just didn't support color in "linux" or "xterm" $TERM modes. I tried using TERM=vt100, TERM=vt200 and TERM=vt500 (as well as the color modes TERM=screen256-color, TERM=vt200-color) but that made things worse, in my opinion. What happened was that YaST was displayed in black and white with no highlighting to show which entry was selected. YaST became pretty much impossible to use.
It turned out that there is an informative page on the openSUSE wiki which deals with YaST Tips and Tricks. There I saw the information "The default setting of the YaST ncurses UI is that the init routine detects the terminal type and automatically chooses the appropriate color theme." However, then I saw the hint:
Since openSUSE 10.3 it's possible to set the color theme manually in /etc/sysconfig/yast2. E.g. if you want a black/white YaST set Y2NCURSES_COLOR_THEME to "mono".After some playing around and testing I found that, to get YaST working in ncurses mode over the serial connection (without messing up YaST over SSH), the following combination did the job:
Change the line Y2NCURSES_COLOR_THEME in the file /etc/sysconfig/yast2 from:
Y2NCURSES_COLOR_THEME=""
to
Y2NCURSES_COLOR_THEME="linux"
and also change:
TERM=screen; export TERM
For me, I then got an acceptable YaST. This is probably a bit of a hacky workaround, but maybe it could help somebody in the know identify the real problem and fix it properly.
That's all for now folks! Here's a screenshot of YaST in ncurses mode on the CuBox, over the serial connection...
openSUSE on CuBox (Day 7)
I started off today with the status that my CuBox image would boot into yast2-firstboot without manual intervention. After configuring the system in yast2-firstboot, I tried rebooting. On reboot, the boot process did not get past "loading initrd". I was told on the opensuse-arm mailing list that the initrd automatically gets overwritten after yast2-firstboot. Given that it was necessary to change ramdiskaddr from 0x300 to 0x500 to even get to yast2-firstboot, I knew where to look to address the reboot problem - to whatever script was called to rewrite the initrd.
Alex Graf put me on the right track. He pointed out that the uboot-setup.tgz file in the JeOS-cubox package also needs to be updated. The contents of this .tgz are used to rewrite the initrd. When you unpack uboot-setup.tgz, you get a directory called kiwi-hook. In this directory are two files. I had forgotten to modify the setupUboot.sh file so that the ramdiskaddr there is also update to 0x5000 from 0x3000.
Once I fixed the setupUboot.sh and recreated uboot-setup.tgz, I called the precheckin.sh script (also in the JeOS-cubox package). This script regenerates the JeOS-cubox.kiwi file using the modifications I had made to the Images.kiwi.in file (i.e. changing the console line from ttyS0,115200n8 to ttySO,115200).
After recreating the new image, I dd'd it over to a mini SD card and tried it out. I got past yast2-firstboot and rebooted. This time I got past the "loading initrd" but the this error occurred:
The bootloader will continue looping to that point, until the power cable is pulled. So now it looks as though the new initrd - the one that is automatically created out of the setupUboot.sh in the kiwi-hooks directory (i.e. the contents of uboot-setup.tgz) somehow contains an illegal instruction. The next task is to identify what is going on there - which instruction is illegal.
Stay tuned! We're getting close.
Alex Graf put me on the right track. He pointed out that the uboot-setup.tgz file in the JeOS-cubox package also needs to be updated. The contents of this .tgz are used to rewrite the initrd. When you unpack uboot-setup.tgz, you get a directory called kiwi-hook. In this directory are two files. I had forgotten to modify the setupUboot.sh file so that the ramdiskaddr there is also update to 0x5000 from 0x3000.
Once I fixed the setupUboot.sh and recreated uboot-setup.tgz, I called the precheckin.sh script (also in the JeOS-cubox package). This script regenerates the JeOS-cubox.kiwi file using the modifications I had made to the Images.kiwi.in file (i.e. changing the console line from ttyS0,115200n8 to ttySO,115200).
After recreating the new image, I dd'd it over to a mini SD card and tried it out. I got past yast2-firstboot and rebooted. This time I got past the "loading initrd" but the this error occurred:
High Capacity: Yes
Capacity: 3965190144
Bus Width: 4-bit
Loading file "/boot.scr" from mmc device 0:1 mmcda1
723 bytes read
## Executing script at 02000000
## Error: "kerneladdr" not defined
## Error: "ramdiskaddr" not defined
Loading file "uImage" from mmc device 0:1 (mmcda1)
3927920 bytes read
Loading file "initrd" from mmc device 0:1 (mmcda1)
undefined instruction
pc : [<9e34e23c>] lr : [<036352b8>]
sp : 035ff530 ip : 03604478 fp : c6b2fd2b
r10: aad350f6 r9 : d13d13bf r8 : 035fffcc
r7 : 8d7ea4d5 r6 : b697c9bf r5 : 45f7c8d6 r4 : 4a59273d
r3 : ffffffff r2 : 00000001 r1 : 007a1200 r0 : 00000000
Flags: nzcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
The bootloader will continue looping to that point, until the power cable is pulled. So now it looks as though the new initrd - the one that is automatically created out of the setupUboot.sh in the kiwi-hooks directory (i.e. the contents of uboot-setup.tgz) somehow contains an illegal instruction. The next task is to identify what is going on there - which instruction is illegal.
Stay tuned! We're getting close.
Mittwoch, 28. November 2012
openSUSE on CuBox (Day 6)
It's been a couple of days since my last update but that's not because I was doing nothing. In fact, I've been investing more work than normal in openSUSE on CuBox these last couple of days. At the end of my last update, I had an image which basically worked and booted without manual intervention. I achieved this by modifying the uboot-image-setup script included in the JeOS-cubox package in the openSUSE:12.2:ARM:Contrib:Cubox project.
It turns out that, whereas my modifications lead to a system that boots each time (without manual intervention through uboot), the same modifications are problematic. This is because they depart from the generic structure that all other openSUSE on ARM devices use to boot. This means that we essentially create a kind of proprietary branch and would have to maintain this all by ourselves - without benefiting from all the hard work going on in the rest of the ARM port (well, not automatically benefiting, that is).
Another issue that my modifications created was the situation where the network interface on the CuBox would not be brought up automatically at each boot. What was happening is that the interface eth0 would not be found on reboot because the MAC address changed. The change happened because of the resetenv that I had inserted in the uboot-image-setup file. Because of this, it was necessary to log in to the CuBox over the serial interface in order to configure the "new" interface through (e.g.) YaST. This meant that each time the network interface id would increment by one - e.g. eth0, eth1, eth2. This was also not ideal.
Thus, what was suggested was that I revoke my submit request and try to continue editing the uboot-image-setup script (as well as the corresponding .kiwi file) to try to figure out exactly what change is needed to get the CuBox to boot. Thus far I think I've narrowed it down to the bootargs line. This line gets added to boot/boot.script in the image by the .kiwi file (in the same uppermost directory as the uboot-image-setup file). In the .kiwi file, the bootargs line appears to have ttyS0,115200n8 whereas the bootargs line I was using in uboot-image-setup had ttyS0,115200 only. I don't know what the 115200n8 is for or if it could even have an effect, but I'm going to change it in the .kiwi file to see if that is the place that is causing the trouble.
I'm out of the house today, without a CuBox, so I won't be able to test (well, I'm in the office in Nuremberg, where there are a couple of CuBox so if I get time, I may be able to test one).
Stay tuned! Check out some of the mail threads that have been generated around openSUSE on CuBox over on the opensuse-arm mailing list:
It turns out that, whereas my modifications lead to a system that boots each time (without manual intervention through uboot), the same modifications are problematic. This is because they depart from the generic structure that all other openSUSE on ARM devices use to boot. This means that we essentially create a kind of proprietary branch and would have to maintain this all by ourselves - without benefiting from all the hard work going on in the rest of the ARM port (well, not automatically benefiting, that is).
Another issue that my modifications created was the situation where the network interface on the CuBox would not be brought up automatically at each boot. What was happening is that the interface eth0 would not be found on reboot because the MAC address changed. The change happened because of the resetenv that I had inserted in the uboot-image-setup file. Because of this, it was necessary to log in to the CuBox over the serial interface in order to configure the "new" interface through (e.g.) YaST. This meant that each time the network interface id would increment by one - e.g. eth0, eth1, eth2. This was also not ideal.
Thus, what was suggested was that I revoke my submit request and try to continue editing the uboot-image-setup script (as well as the corresponding .kiwi file) to try to figure out exactly what change is needed to get the CuBox to boot. Thus far I think I've narrowed it down to the bootargs line. This line gets added to boot/boot.script in the image by the .kiwi file (in the same uppermost directory as the uboot-image-setup file). In the .kiwi file, the bootargs line appears to have ttyS0,115200n8 whereas the bootargs line I was using in uboot-image-setup had ttyS0,115200 only. I don't know what the 115200n8 is for or if it could even have an effect, but I'm going to change it in the .kiwi file to see if that is the place that is causing the trouble.
I'm out of the house today, without a CuBox, so I won't be able to test (well, I'm in the office in Nuremberg, where there are a couple of CuBox so if I get time, I may be able to test one).
Stay tuned! Check out some of the mail threads that have been generated around openSUSE on CuBox over on the opensuse-arm mailing list:
Freitag, 16. November 2012
openSUSE on CuBoX (Day 5)
Today I decided to try to get to grips with building a new, modified image for the CuBox. In my last post I explained how easy it is to build the standard openSUSE image for CuBox by simply checking out the project and using the osc tool to build. The procedure here is basically the same, except this time I'm going to edit some files to try to make the CuBox boot automatically (you'll remember from my first post that manual intervention is currently needed at the Uboot stage).
I cd'd into my branch of openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox and ran 'osc up' to make sure I was working on the latest sources.
Given that the openSUSE image itself actually works (i.e. once you get past the Uboot stage, the image boots and you can log in and play around with it), I figured that the real issue must be the boot.scr script, which is a generated file. You can't just go and edit boot.scr and hope to be successful - that file is created by a mkimage command.
In the checked out branch I found a file called uboot-image-setup. "Aha", I thought, "this has to be it". That file contained the following:
For whatever reason, this was simply not working. You can see why in my first and second posts about openSUSE on CuBox (i.e. systems hangs where the kernel is supposed to boot). I decided to see if I could add the commands that I used when manually intervening (see http://c-farrell.blogspot.de/2012/11/opensuse-on-cubox-day-2.html) to the script and see would it work. It did - kind of. Without getting into further details, here is the uboot-image-setup that worked for me:
I submitted my change to uboot-image-setup to the openSUSE project. If it's accepted, we'll hopefully have a new CuBox image available for download here soon.
I'm going to have a look through the Solid Run Wiki and Forums next, to see if I can get an idea of what we'd need to do to get graphics up and running. I imagine there will be a hard brick (proprietary graphics driver) wall that we'll run into, but maybe we can make some progress before that and then try to solve the brick wall problem some other way.
I cd'd into my branch of openSUSE:12.2:ARM:Contrib:Cubox/JeOS-cubox and ran 'osc up' to make sure I was working on the latest sources.
Given that the openSUSE image itself actually works (i.e. once you get past the Uboot stage, the image boots and you can log in and play around with it), I figured that the real issue must be the boot.scr script, which is a generated file. You can't just go and edit boot.scr and hope to be successful - that file is created by a mkimage command.
In the checked out branch I found a file called uboot-image-setup. "Aha", I thought, "this has to be it". That file contained the following:
#!/bin/bash
set -x
file=boot/boot.script
echo 'printenv kerneladdr || setenv kerneladdr ${kernel_addr_r}' >> $file
echo 'printenv ramdiskaddr|| setenv ramdiskaddr ${ramdisk_addr_r}' >> $file
#CuBox Hack
echo 'if itest 1$arcNumber == 13905; then' >> $file
echo ' setenv kerneladdr 0x2000000' >> $file
echo ' setenv ramdiskaddr 0x3000000' >> $file
echo 'fi' >> $file
echo -n 'setenv bootcmd "' >> $file
echo -n 'ext2load mmc 0:1 ${kerneladdr} boot/linux.vmx; ' >> $file
echo -n 'ext2load mmc 0:1 ${ramdiskaddr} boot/initrd.uboot; ' >> $file
echo 'bootm ${kerneladdr} ${ramdiskaddr}";' >> $file
echo 'boot'
mkopts="-A arm -O linux -a 0 -e 0 -T script -C none";
inputf="boot/boot.script";
result="boot/boot.scr";
if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then
echo "Failed to create uboot script image"
exit 1
fi
For whatever reason, this was simply not working. You can see why in my first and second posts about openSUSE on CuBox (i.e. systems hangs where the kernel is supposed to boot). I decided to see if I could add the commands that I used when manually intervening (see http://c-farrell.blogspot.de/2012/11/opensuse-on-cubox-day-2.html) to the script and see would it work. It did - kind of. Without getting into further details, here is the uboot-image-setup that worked for me:
#!/bin/bashI'm not entirely sure if the resetenv is absolutely necessary. I hope not, and I'll have to test without that line, but for now, the CuBox boots without manual intervention. You get a dog ugly YaST firstboot, which you can use to initially configure your CuBox. I've already asked Juergen Weigert if there is anything that can be done to get YaST to look a bit better when using screen. Here's a screenshot - as you can see the colours are all screwed up. YaST is functional, though.
set -x
file=boot/boot.script
echo 'resetenv' >> $file
echo 'setenv kerneladdr 0x2000000' >> $file
echo 'setenv ramdiskaddr 0x3000000' >> $file
echo 'ext2load mmc 0:1 0x2000000 boot/linux.vmx' >> $file
echo 'ext2load mmc 0:1 0x3000000 boot/initrd.uboot' >> $file
echo -n 'setenv bootargs "' >> $file
echo 'console=ttyS0,115200 root=/dev/mmcblk0p2"' >> $file
echo 'bootm 0x2000000 0x3000000' >> $file
echo 'boot' >> $file
mkopts="-A arm -O linux -a 0 -e 0 -T script -C none";
inputf="boot/boot.script";
result="boot/boot.scr";
if ! mkimage $mkopts -n 'Boot-Script' -d $inputf $result;then
echo "Failed to create uboot script image"
exit 1
fi
I submitted my change to uboot-image-setup to the openSUSE project. If it's accepted, we'll hopefully have a new CuBox image available for download here soon.
I'm going to have a look through the Solid Run Wiki and Forums next, to see if I can get an idea of what we'd need to do to get graphics up and running. I imagine there will be a hard brick (proprietary graphics driver) wall that we'll run into, but maybe we can make some progress before that and then try to solve the brick wall problem some other way.
Savita Halappanavar
It is quite difficult to decide on how to start to address this topic. The bare facts of the matter are, that an Indian national in the seventeeth week of pregnancy was brought to a hospital in Galway (Ireland) as she was suffering intense pain. Upon examination it was discovered that the foetus was no longer viable and that a severe risk to the life of the woman had been brought about. I think that it is relatively safe to state that those facts are undisputed, though I learned of them through hearsay only.
It is at this stage that the reports of what happened begin to differ and it becomes evident that there are various tales being told. Apparently, reasonable medical opinion would advise that an immediate termination of the pregnancy be brought about to mitigate the danger to the life of the woman. However, the husband of the woman was (apparently) told that such a termination was not possible in the Republic of Ireland because "[the Republic of Ireland is] a catholic country" and that as long as a foetal heartbeat could be detected, a termination would not be (legally) possible.
The sad facts of the matter are that the woman died thereafter. I believe it is undisputed that a timely termination would have saved her life. The story attracted huge attention in Ireland and was also reported in Germany. In India, there were also various newspaper reports. Almost invariably, the reaction appeared to be that the unfortunate woman died because Ireland's legal system protected the right of her unborn child to a higher degree than it protected her right to life.
Without getting involved in relatively futile quasi religious debate on whether the termination of pregnancy is morally acceptable or not, I think it is useful to look at the actual legal background behind abortion in Ireland.
The Irish Constitution was approved by referendum in 1937. Historians agree that the catholic church (which was by far the strongest religious body in Ireland back then and still remains dominant today) - in particular Archbishop McQuaid (he later became Archbishop, that is) exerted considerable influence on the drafters. In fact, while protecting freedom of religion and prohibiting an established church, the 1937 constitution did (in Art 44.1.2) "[recognise] the special position of the Holy Catholic Apostolic and Roman Church as the guardian of the Faith professed by the great majority of the citizens". This reference was only removed in the Fifth Amendment in 1972. At the time the consitution was approved by referendum, abortion was officially illegal according to Section 57 of the Offences Against the Person Act from 1861. No provision of the original constitution specifically addressed abortion. The Eighth Amendment to the constitution in 1983 introduced a new clause into the Fundamental Rights section - Article 40.3.3 which stated: "The State acknowledges the right to life of the unborn and, with due regard to the equal right to life of the mother, guarantees in its laws to respect, and, as far as practicable, by its laws to defend and vindicate that right." This clause served to make it impossible for the legislature to create a law in the future that would legalise abortion.
As can be seen from the text of the Eighth Amendment, however, that amendment did not per se completely outlaw abortion - what it did do was put the right to life of the unborn child on par with the right to life of the mother - meaning that it was at least perceivable that the legislature could still pass a law which allowed abortion when there was a danger to the life of the mother.
In 1992 the Supreme Court (the most superior court in Ireland which is ultimately responsible for interpreting the constitution - akin the Supreme Court of the United States) decided the Attorney General vs X case. This was a case where a 14 year old girl was raped and as a result of this was pregnant. The girl and her parents wished to travel to England to terminate the pregnancy (in fact, they had already arrived in England). The Attorney General applied for (and was granted, in the High Court) an interlocutory injunction to prohibit the girl from travelling outside the country for the purpose of terminating the pregnancy. The girl appealed to the Supreme Court.
The Supreme Court overturned the interlocutory injunction, ruling that the real test to be applied should be:
(see paragraph 37 http://www.bailii.org/ie/cases/IESC/1992/1.html - this was delivered by Chief Justice Finlay but see also Justice Egan's commentary at paragraph 183).
Thus, after Attorney General vs X it seemed as though it would not be unconstitutional for the legislature to enact a law which allowed termination of pregnancy if it could be established "as a matter of probability that there is a real and substantial risk to the life, as distinct from the health ... of the mother".
In the wake of the death of the woman in the hospital in Galway, much of the outrage seems to be aimed at a perceived prohibition of abortion in Ireland. As can be seen from the Supreme Court decision, however, in the case of the woman in Galway, it would have been perfectly legal to terminate the pregnancy had the irish legislature enacted a law since the X case (1992) to create the exception to allow an abortion where there is a real and substantial danger to the life of the mother.
The real scandal here is, that successive governments did absolutely nothing to enact such legislation. In fact, just a couple of months ago the United Left (a relatively new political group in the parliament) introduced a bill which would have at least brought about a parliamentary debate on legislating for the X Case. It did not even receive enough votes for that! You can read one side of those developments here: http://www.claredaly.ie/labour-and-fine-gael-bear-responsibility-for-death-of-woman-who-was-denied-abortion/
In summary, it was successive irish governments' failure to enact legislation that brought about the situation where the doctor(s) in the Galway hospital departed from what reasonable medical practitioners would have done - to terminate the pregnancy to save the woman's life (that last sentence is opinion only - I do not know the full facts necessary).
It is at this stage that the reports of what happened begin to differ and it becomes evident that there are various tales being told. Apparently, reasonable medical opinion would advise that an immediate termination of the pregnancy be brought about to mitigate the danger to the life of the woman. However, the husband of the woman was (apparently) told that such a termination was not possible in the Republic of Ireland because "[the Republic of Ireland is] a catholic country" and that as long as a foetal heartbeat could be detected, a termination would not be (legally) possible.
The sad facts of the matter are that the woman died thereafter. I believe it is undisputed that a timely termination would have saved her life. The story attracted huge attention in Ireland and was also reported in Germany. In India, there were also various newspaper reports. Almost invariably, the reaction appeared to be that the unfortunate woman died because Ireland's legal system protected the right of her unborn child to a higher degree than it protected her right to life.
Without getting involved in relatively futile quasi religious debate on whether the termination of pregnancy is morally acceptable or not, I think it is useful to look at the actual legal background behind abortion in Ireland.
The Irish Constitution was approved by referendum in 1937. Historians agree that the catholic church (which was by far the strongest religious body in Ireland back then and still remains dominant today) - in particular Archbishop McQuaid (he later became Archbishop, that is) exerted considerable influence on the drafters. In fact, while protecting freedom of religion and prohibiting an established church, the 1937 constitution did (in Art 44.1.2) "[recognise] the special position of the Holy Catholic Apostolic and Roman Church as the guardian of the Faith professed by the great majority of the citizens". This reference was only removed in the Fifth Amendment in 1972. At the time the consitution was approved by referendum, abortion was officially illegal according to Section 57 of the Offences Against the Person Act from 1861. No provision of the original constitution specifically addressed abortion. The Eighth Amendment to the constitution in 1983 introduced a new clause into the Fundamental Rights section - Article 40.3.3 which stated: "The State acknowledges the right to life of the unborn and, with due regard to the equal right to life of the mother, guarantees in its laws to respect, and, as far as practicable, by its laws to defend and vindicate that right." This clause served to make it impossible for the legislature to create a law in the future that would legalise abortion.
As can be seen from the text of the Eighth Amendment, however, that amendment did not per se completely outlaw abortion - what it did do was put the right to life of the unborn child on par with the right to life of the mother - meaning that it was at least perceivable that the legislature could still pass a law which allowed abortion when there was a danger to the life of the mother.
In 1992 the Supreme Court (the most superior court in Ireland which is ultimately responsible for interpreting the constitution - akin the Supreme Court of the United States) decided the Attorney General vs X case. This was a case where a 14 year old girl was raped and as a result of this was pregnant. The girl and her parents wished to travel to England to terminate the pregnancy (in fact, they had already arrived in England). The Attorney General applied for (and was granted, in the High Court) an interlocutory injunction to prohibit the girl from travelling outside the country for the purpose of terminating the pregnancy. The girl appealed to the Supreme Court.
The Supreme Court overturned the interlocutory injunction, ruling that the real test to be applied should be:
"if it is established as a matter of probability that there is a real and substantial risk to the life, as distinct from the health, of the mother, which can only be avoided by the termination of her pregnancy, such termination is permissible, having regard to the true interpretation of Article 40,s.3, sub-s. 3 of the Constitution"
(see paragraph 37 http://www.bailii.org/ie/cases/IESC/1992/1.html - this was delivered by Chief Justice Finlay but see also Justice Egan's commentary at paragraph 183).
Thus, after Attorney General vs X it seemed as though it would not be unconstitutional for the legislature to enact a law which allowed termination of pregnancy if it could be established "as a matter of probability that there is a real and substantial risk to the life, as distinct from the health ... of the mother".
In the wake of the death of the woman in the hospital in Galway, much of the outrage seems to be aimed at a perceived prohibition of abortion in Ireland. As can be seen from the Supreme Court decision, however, in the case of the woman in Galway, it would have been perfectly legal to terminate the pregnancy had the irish legislature enacted a law since the X case (1992) to create the exception to allow an abortion where there is a real and substantial danger to the life of the mother.
The real scandal here is, that successive governments did absolutely nothing to enact such legislation. In fact, just a couple of months ago the United Left (a relatively new political group in the parliament) introduced a bill which would have at least brought about a parliamentary debate on legislating for the X Case. It did not even receive enough votes for that! You can read one side of those developments here: http://www.claredaly.ie/labour-and-fine-gael-bear-responsibility-for-death-of-woman-who-was-denied-abortion/
In summary, it was successive irish governments' failure to enact legislation that brought about the situation where the doctor(s) in the Galway hospital departed from what reasonable medical practitioners would have done - to terminate the pregnancy to save the woman's life (that last sentence is opinion only - I do not know the full facts necessary).
Mittwoch, 14. November 2012
openSUSE on CuBox (Day 4)
I left off yesterday wondering how difficult it would be to start building openSUSE images for the CuBox. After searching a bit I found that the KIWI tool seems to be the right one for the job - and indeed it is the tool that is used in the openSUSE Build Service to get this kind of job done on a huge scale. So far, so good. I read through the instructions over on http://en.opensuse.org/SDB:KIWI_Cookbook_Start_Cooking to see what the basic steps for cooking up a raw image are.
First off, I needed the actual content of the image - i.e. the kernel and root filesystem. Conveniently, the openSUSE ARM contributors have already got one cooked up that they "made earlier". To get in on my development machine (my laptop), all I needed to do was (I already had the osc tool installed):
That left me with the project fully checked out on my local disk. I started fooling around with kiwi, trying to configure, prepare and build an image for CuBox - a complete waste of time. It turns out that the Build Service has this covered already. No need for messing around with local kiwi builds. To get a raw image for CuBox all I had to do was:
Make sure qemu-linux-user is installed beforehand though - actually, you'd be well advised to follow all the (brief) instructions about getting started with ARM development for openSUSE over at http://en.opensuse.org/openSUSE:ARM_distribution_howto in order to get your development machine ready.
I didn't go making changes to the image yet - I just wanted to see how easy or difficult it is to create an image by myself.
In summary, building images for CuBox is child's play - the openSUSE ARM people have already done the grunt work and the Build Service takes all the sweat and cursing out of the actual cooking.
Next, time for some real work - debugging the booting of the CuBox to find out why manual intervention is needed during UBoot, to get the kernel to boot.
First off, I needed the actual content of the image - i.e. the kernel and root filesystem. Conveniently, the openSUSE ARM contributors have already got one cooked up that they "made earlier". To get in on my development machine (my laptop), all I needed to do was (I already had the osc tool installed):
osc bco openSUSE:12.2:ARM:Contrib:Cubox JeOS-cubox
That left me with the project fully checked out on my local disk. I started fooling around with kiwi, trying to configure, prepare and build an image for CuBox - a complete waste of time. It turns out that the Build Service has this covered already. No need for messing around with local kiwi builds. To get a raw image for CuBox all I had to do was:
osc build images armv7l JeOS-cubox.kiwi
Make sure qemu-linux-user is installed beforehand though - actually, you'd be well advised to follow all the (brief) instructions about getting started with ARM development for openSUSE over at http://en.opensuse.org/openSUSE:ARM_distribution_howto in order to get your development machine ready.
I didn't go making changes to the image yet - I just wanted to see how easy or difficult it is to create an image by myself.
In summary, building images for CuBox is child's play - the openSUSE ARM people have already done the grunt work and the Build Service takes all the sweat and cursing out of the actual cooking.
Next, time for some real work - debugging the booting of the CuBox to find out why manual intervention is needed during UBoot, to get the kernel to boot.
Abonnieren
Posts (Atom)