Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(2) |
|
2
|
3
|
4
|
5
(1) |
6
(3) |
7
(17) |
8
|
|
9
|
10
(7) |
11
(8) |
12
(5) |
13
|
14
|
15
|
|
16
|
17
(3) |
18
|
19
|
20
|
21
|
22
|
|
23
|
24
|
25
(1) |
26
(2) |
27
|
28
|
29
|
|
30
(1) |
|
|
|
|
|
|
|
From: Lonnie A. <li...@lo...> - 2008-11-30 02:42:02
|
While I remember... In the script /etc/init.d/dynamicdns In the init() function We should add an --- else rm -f /tmp/etc/inadyn.conf --- This allows... /etc/init.d/dynamicdns stop /usr/sbin/gen-rc-conf /etc/init.d/dynamicdns init with new rc.conf values, if one of the new values is "", then the dyndns should be disabled. (Currently it uses old values) Thanks, Lonnie |
|
From: Darrick H. <dha...@dj...> - 2008-11-26 05:36:57
|
Well I tagged 0.6.2 and am currently building the release files. These will be uploaded to Sourceforge in the next few days. When they are available, I'll send a message to the various lists. Many, many improvements over 0.6.1. Darrick Philip Prindeville wrote: > Sigh. > > Yeah, I would have liked to have gotten the wireless support done, > but... my request for assistance with the configuration scripts went > unanswered. > > So we'll have to leave Wifi as "undone" for now. > > Maybe for 0.7. > > -Philip > > Darrick Hartman wrote: >> I've been testing 0.6-2111. Everything looks good to go (including the >> new gui interface to use arno's firewall). Are there any other >> outstanding issues that should be addressed prior to releasing 0.6.2? >> I'm pretty happy with what we have in there and would like to cut the >> release. >> >> The list of improvements over 0.6.1 is quite substantial. >> >> Unless there are major objections, I'll do so later today. >> >> Darrick >> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Philip P. <phi...@re...> - 2008-11-26 00:16:24
|
Sigh. Yeah, I would have liked to have gotten the wireless support done, but... my request for assistance with the configuration scripts went unanswered. So we'll have to leave Wifi as "undone" for now. Maybe for 0.7. -Philip Darrick Hartman wrote: > I've been testing 0.6-2111. Everything looks good to go (including the > new gui interface to use arno's firewall). Are there any other > outstanding issues that should be addressed prior to releasing 0.6.2? > I'm pretty happy with what we have in there and would like to cut the > release. > > The list of improvements over 0.6.1 is quite substantial. > > Unless there are major objections, I'll do so later today. > > Darrick > |
|
From: Darrick H. <dha...@dj...> - 2008-11-25 17:23:56
|
I've been testing 0.6-2111. Everything looks good to go (including the new gui interface to use arno's firewall). Are there any other outstanding issues that should be addressed prior to releasing 0.6.2? I'm pretty happy with what we have in there and would like to cut the release. The list of improvements over 0.6.1 is quite substantial. Unless there are major objections, I'll do so later today. Darrick |
|
From: Philip P. <phi...@re...> - 2008-11-17 17:50:01
|
Kristian Kielhofner wrote: > On Mon, Nov 17, 2008 at 2:47 AM, Philip Prindeville > <phi...@re...> wrote: > ..snip.. > >> BIOS doesn't seem to be reporting DMI, and the option "ide=nodma" needs to >> be retired... >> > > The new option is now "hdx=nodma". > Ah. But we don't know what drive to apply that to. It could be hda or hdb, right? -Philip |
|
From: Kristian K. <kki...@st...> - 2008-11-17 16:04:23
|
On Mon, Nov 17, 2008 at 2:47 AM, Philip Prindeville <phi...@re...> wrote: ..snip.. > > BIOS doesn't seem to be reporting DMI, and the option "ide=nodma" needs to > be retired... The new option is now "hdx=nodma". -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com |
|
From: Philip P. <phi...@re...> - 2008-11-17 07:47:20
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Apologies for the HTML message, but I wanted to highlight some stuff...<br>
<br>
Seeing the following when booting trunk-2085:<br>
<br>
<pre>Trying kexec...
Starting new kernel
Linux version 2.6.25.19-astlinux (philipp@tosh) (gcc version 4.1.2) #1 PREEMPT Sun Nov 16 12:44:25 PST 2008
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000100 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
256MB LOWMEM available.
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
<font color="#cc0000"><b>DMI not present or invalid.</b></font>
Allocating PCI resources starting at 20000000 (gap: 10000000:eff00000)
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/ram0 rw init=/linuxrc astimg=astlinux-trunk-2085.run astlinux=net5501 astkd=auto asturw=auto astlive ide=nodma console=ttyS0,19200n8
ide_setup: ide=nodma : Prevented DMA
<font color="#cc0000"><b> -- OBSOLETE OPTION, WILL BE REMOVED SOON!</b></font>
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Detected 433.258 MHz processor.
Console: colour dummy device 80x25
console [ttyS0] enabled
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256228k/262144k available (1682k kernel code, 5388k reserved, 706k data, 160k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xffffb000 - 0xfffff000 ( 16 kB)
vmalloc : 0xd0800000 - 0xffff9000 ( 759 MB)
lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
.init : 0xc0358000 - 0xc0380000 ( 160 kB)
.data : 0xc02a48a0 - 0xc03550e0 ( 706 kB)
.text : 0xc0100000 - 0xc02a48a0 (1682 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
Calibrating delay using timer specific routine.. 867.44 BogoMIPS (lpj=433723)
Mount-cache hash table entries: 512
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 128K (32 bytes/line)
Compat vDSO mapped to ffffe000.
CPU: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 0k freed
net_namespace: 540 bytes
NET: Registered protocol family 16
<font color="#cc0000"><b>geode: Couldn't initialize 'geode-pms'
geode: Couldn't initialize 'geode-acpi'</b></font>
geode-mfgpt: 8 MFGPT timers available.
geode-mfgpt: Registered timer 0
mfgpt-timer: registering the MFGPT timer as a clock event.
PCI: PCI BIOS revision 2.01 entry at 0xfac61, last bus=0
PCI: Using configuration type 1
Setting up standard PCI resources
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 426k freed
scx200: NatSemi SCx200 Driver
squashfs: version 3.4 (2008/08/26) Phillip Lougher
Registering unionfs 2.5 (for 2.6.25.17)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD5536: 0000:00:14.2 (rev 01) UDMA100 controller
AMD5536: IDE controller (0x1022:0x209a rev 0x01) at PCI slot 0000:00:14.2
AMD5536: not 100% native mode: will probe irqs later
AMD5536: IDE port disabled
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:PIO, hdb:PIO
hda: SanDisk SDCFH-1024, CFA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 2001888 sectors (1024 MB) w/1KiB Cache, CHS=1986/16/63
hda: hda1 hda2 hda3
<font color="#cc0000"><b>Driver 'sd' needs updating - please use bus_type methods</b></font>
ehci_hcd 0000:00:15.1: EHCI Host Controller
ehci_hcd 0000:00:15.1: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:15.1: irq 15, io mem 0xa0021000
ehci_hcd 0000:00:15.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
ohci_hcd 0000:00:15.0: OHCI Host Controller
ohci_hcd 0000:00:15.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:15.0: irq 15, io mem 0xa0020000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 4 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 160k freed
Looking for AstLinux image...
AstLinux image found!
Configuring for unionfs...
Checking asturw filesystem
ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda3 is mounted.
Asturw filesystem clean.
Copying AstLinux files to RAM...
unmounting squashfs image
Pivoting...
init started: BusyBox v1.11.2 (2008-11-16 13:04:14 PST)
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
eth0: VIA Rhine III (Management Adapter) at 0xa0004000, 00:00:24:c9:30:00, IRQ 11.
eth0: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
eth1: VIA Rhine III (Management Adapter) at 0xa0004100, 00:00:24:c9:30:01, IRQ 5.
eth1: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
eth2: VIA Rhine III (Management Adapter) at 0xa0004200, 00:00:24:c9:30:02, IRQ 9.
eth2: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000.
eth3: VIA Rhine III (Management Adapter) at 0xa0004300, 00:00:24:c9:30:03, IRQ 12.
eth3: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.
geode-aes: GEODE AES engine enabled.
AMD Geode RNG detected
going to runlevel default...
</pre>
So we're still missing a few things. Missing the i2c drivers, and the
WDT watchdog timer.<br>
<br>
BIOS doesn't seem to be reporting DMI, and the option "ide=nodma" needs
to be retired...<br>
<br>
Was wondering about the following changes:<br>
<br>
<pre>Index: target/device/net5501/linux.config
===================================================================
--- target/device/net5501/linux.config (revision 2085)
+++ target/device/net5501/linux.config (working copy)
@@ -1160,7 +1160,7 @@
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
-# CONFIG_SCx200_GPIO is not set
+CONFIG_SCx200_GPIO=m
CONFIG_PC8736x_GPIO=m
CONFIG_NSC_GPIO=m
CONFIG_CS5535_GPIO=m
@@ -1197,6 +1197,9 @@
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
+CONFIG_SCx200_I2C=m
+CONFIG_SCx200_I2C_SCL=12
+CONFIG_SCx200_I2C_SDA=13
CONFIG_SCx200_ACB=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
@@ -1320,8 +1323,8 @@
# CONFIG_IT8712F_WDT is not set
# CONFIG_HP_WATCHDOG is not set
CONFIG_SC1200_WDT=m
-# CONFIG_SCx200_WDT is not set
-# CONFIG_PC87413_WDT is not set
+CONFIG_SCx200_WDT=m
+CONFIG_PC87413_WDT=m
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_SBC7240_WDT is not set
@@ -1625,11 +1628,13 @@
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
-CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_CLASS=m
#
# LED drivers
#
+CONFIG_LEDS_NET48XX=m
+# CONFIG_LEDS_WRAP is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
#
</pre>
</body>
</html>
|
|
From: Michael K. <mk...@we...> - 2008-11-12 10:45:28
|
> > >> >>> I'll commit a fix for two things (the compression included) shortly... >>> >> >> Kris already committed the fix. >> >> Darrick >> > >Sigh. > >Too late. > >Anyone know why sourceforge is taking 40+ minutes to send the emails out >about commits? > >-Philip There seem to be often problem with the SVN at Sourceforge. I got every day errors like ----------------------------------------- An Exception Has Occurred The root "astlinux" is unknown. If you believe the value is correct, then please double-check your configuration. HTTP Response Status 404 Repository not found ----------------------------------------- when I ty to reach http://astlinux.svn.sourceforge.net/viewvc/astlinux?view=rev Michael -- Email: mailto:mk...@we... |
|
From: Philip P. <phi...@re...> - 2008-11-12 05:42:12
|
Lonnie Abelbeck wrote: > Philip, > > Awesome explanation. > > In short, you are saying, never use... > > if `shell-command`; then > > Instead, use... > > shell-command >/dev/null > if [ $? -eq 0 ]; then You can do that, or you can do: if shell-command >/dev/null; then ... and that will work too. All depends on what you want to do with stdout/stderr... > > Correct? > > Obviously the original must work in this special case, because it does > work, but this is a good time to start good habits. > > Philip, would you prefer me to make some of these changes, or are you > willing to make them yourself? I'm happy to review them, but I'd prefer to leave you with ownership of your stuff. > > Thanks much, > Lonnie > > PS: Don't take a look at Kristian's /usr/sbin/astup code. :-) Yeah let's not go there. ;-) Which reminds me... need to get him a spacebar for his keyboard as a stocking stuffer... -Philip > > > On Nov 11, 2008, at 8:28 PM, Philip Prindeville wrote: > >>> >>>> + >>>> + if `mount -t tmpfs -o size=56m none /tmp/up >/dev/null 2>&1`; then >>>> >>> >>> Ditto. >>> >>> Also, you can use $? to get the exit code, etc. i.e. >>> >>> if ! mount -t tmpfs -o size=56m none /tmp/up >/dev/null; then >>> >>> or: >>> >>> mount -t tmpfs -o size=56m none /tmp/up >/dev/null >>> if [ $? -ne 0 ]; then >>> rmdir /tmp/up >>> return 1 >>> fi >> >> Ok, here's the thing. >> >> if `shell-command`; then >> >> doesn't work the way you think it does. >> >> shell-command gets run, the whatever output of that command results, >> then gets executed *again* as a command, whose return value is then used >> for the conditional evaluation. >> >> Example: >> >> #!/bin/sh -x >> >> if `echo true`; then >> echo true >> else >> echo false >> fi >> >> if `echo false`; then >> echo true >> else >> echo false >> fi >> >> if `echo maybe`; then >> echo true >> else >> echo false >> fi >> >> if `cat /dev/null`; then >> echo true >> else >> echo false >> fi >> >> if `true`; then >> echo true >> else >> echo false >> fi >> >> if `false`; then >> echo true >> else >> echo false >> fi >> >> >> results in: >> >> ++ echo true >> + true >> + echo true >> true >> ++ echo false >> + false >> + echo false >> false >> ++ echo maybe >> + maybe >> /tmp/foo: line 15: maybe: command not found >> + echo false >> false >> ++ cat /dev/null >> + echo true >> true >> ++ true >> + echo true >> true >> ++ false >> + echo false >> false >> >> The last 3 cases are interesting... it shows that if result of >> evaluating shell-command is the empty string, then the exit-code of >> shell-command is used instead. >> >> This probably isn't what you're intending... and there are some >> interesting side effects of writing code this way. >> >> For instance, if I placed a script called "sha1sum" in your search path, >> and had it do: >> >> #!/bin/sh >> >> echo "/sbin/poweroff" >> >> >> then I could do a denial of service attack on your machine when we hit: >> >> if `sha1sum -cs $VER.tar.gz.sha1`; then >> >> >> sha1sum would echo the command /sbin/poweroff, which would then be run >> by the shell to get its exit-value... >> >> Not quite what you intended! >> >> By the way, you can put: >> >> exec >/dev/null >> >> at the top of your script, and that will make sure that none of the >> output (well, stdout) ever gets seen by the caller... >> >> -Philip > |
|
From: Lonnie A. <li...@lo...> - 2008-11-12 04:12:45
|
Philip,
For handing the if `` stuff, how about this...
--
test_cmd()
{
eval "$1" >/dev/null
return $?
}
if test_cmd "sha1sum -cs $VER.run.sha1"; then
echo success
else
echo failure
fi
--
Do you see any problems with this approach?
Lonnie
----------------
Philip,
Awesome explanation.
In short, you are saying, never use...
if `shell-command`; then
Instead, use...
shell-command >/dev/null
if [ $? -eq 0 ]; then
Correct?
Obviously the original must work in this special case, because it does
work, but this is a good time to start good habits.
Philip, would you prefer me to make some of these changes, or are you
willing to make them yourself?
Thanks much,
Lonnie
PS: Don't take a look at Kristian's /usr/sbin/astup code. :-)
On Nov 11, 2008, at 8:28 PM, Philip Prindeville wrote:
>>
>>> +
>>> + if `mount -t tmpfs -o size=56m none /tmp/up >/dev/null 2>&1`;
>>> then
>>>
>>
>> Ditto.
>>
>> Also, you can use $? to get the exit code, etc. i.e.
>>
>> if ! mount -t tmpfs -o size=56m none /tmp/up >/dev/null; then
>>
>> or:
>>
>> mount -t tmpfs -o size=56m none /tmp/up >/dev/null
>> if [ $? -ne 0 ]; then
>> rmdir /tmp/up
>> return 1
>> fi
>
> Ok, here's the thing.
>
> if `shell-command`; then
>
> doesn't work the way you think it does.
>
> shell-command gets run, the whatever output of that command results,
> then gets executed *again* as a command, whose return value is then
> used
> for the conditional evaluation.
>
> Example:
>
> #!/bin/sh -x
>
> if `echo true`; then
> echo true
> else
> echo false
> fi
>
> if `echo false`; then
> echo true
> else
> echo false
> fi
>
> if `echo maybe`; then
> echo true
> else
> echo false
> fi
>
> if `cat /dev/null`; then
> echo true
> else
> echo false
> fi
>
> if `true`; then
> echo true
> else
> echo false
> fi
>
> if `false`; then
> echo true
> else
> echo false
> fi
>
>
> results in:
>
> ++ echo true
> + true
> + echo true
> true
> ++ echo false
> + false
> + echo false
> false
> ++ echo maybe
> + maybe
> /tmp/foo: line 15: maybe: command not found
> + echo false
> false
> ++ cat /dev/null
> + echo true
> true
> ++ true
> + echo true
> true
> ++ false
> + echo false
> false
>
> The last 3 cases are interesting... it shows that if result of
> evaluating shell-command is the empty string, then the exit-code of
> shell-command is used instead.
>
> This probably isn't what you're intending... and there are some
> interesting side effects of writing code this way.
>
> For instance, if I placed a script called "sha1sum" in your search
> path,
> and had it do:
>
> #!/bin/sh
>
> echo "/sbin/poweroff"
>
>
> then I could do a denial of service attack on your machine when we
> hit:
>
> if `sha1sum -cs $VER.tar.gz.sha1`; then
>
>
> sha1sum would echo the command /sbin/poweroff, which would then be run
> by the shell to get its exit-value...
>
> Not quite what you intended!
>
> By the way, you can put:
>
> exec >/dev/null
>
> at the top of your script, and that will make sure that none of the
> output (well, stdout) ever gets seen by the caller...
>
> -Philip
|
|
From: Lonnie A. <li...@lo...> - 2008-11-12 03:14:41
|
Philip, Awesome explanation. In short, you are saying, never use... if `shell-command`; then Instead, use... shell-command >/dev/null if [ $? -eq 0 ]; then Correct? Obviously the original must work in this special case, because it does work, but this is a good time to start good habits. Philip, would you prefer me to make some of these changes, or are you willing to make them yourself? Thanks much, Lonnie PS: Don't take a look at Kristian's /usr/sbin/astup code. :-) On Nov 11, 2008, at 8:28 PM, Philip Prindeville wrote: >> >>> + >>> + if `mount -t tmpfs -o size=56m none /tmp/up >/dev/null 2>&1`; >>> then >>> >> >> Ditto. >> >> Also, you can use $? to get the exit code, etc. i.e. >> >> if ! mount -t tmpfs -o size=56m none /tmp/up >/dev/null; then >> >> or: >> >> mount -t tmpfs -o size=56m none /tmp/up >/dev/null >> if [ $? -ne 0 ]; then >> rmdir /tmp/up >> return 1 >> fi > > Ok, here's the thing. > > if `shell-command`; then > > doesn't work the way you think it does. > > shell-command gets run, the whatever output of that command results, > then gets executed *again* as a command, whose return value is then > used > for the conditional evaluation. > > Example: > > #!/bin/sh -x > > if `echo true`; then > echo true > else > echo false > fi > > if `echo false`; then > echo true > else > echo false > fi > > if `echo maybe`; then > echo true > else > echo false > fi > > if `cat /dev/null`; then > echo true > else > echo false > fi > > if `true`; then > echo true > else > echo false > fi > > if `false`; then > echo true > else > echo false > fi > > > results in: > > ++ echo true > + true > + echo true > true > ++ echo false > + false > + echo false > false > ++ echo maybe > + maybe > /tmp/foo: line 15: maybe: command not found > + echo false > false > ++ cat /dev/null > + echo true > true > ++ true > + echo true > true > ++ false > + echo false > false > > The last 3 cases are interesting... it shows that if result of > evaluating shell-command is the empty string, then the exit-code of > shell-command is used instead. > > This probably isn't what you're intending... and there are some > interesting side effects of writing code this way. > > For instance, if I placed a script called "sha1sum" in your search > path, > and had it do: > > #!/bin/sh > > echo "/sbin/poweroff" > > > then I could do a denial of service attack on your machine when we > hit: > > if `sha1sum -cs $VER.tar.gz.sha1`; then > > > sha1sum would echo the command /sbin/poweroff, which would then be run > by the shell to get its exit-value... > > Not quite what you intended! > > By the way, you can put: > > exec >/dev/null > > at the top of your script, and that will make sure that none of the > output (well, stdout) ever gets seen by the caller... > > -Philip |
|
From: Philip P. <phi...@re...> - 2008-11-12 02:28:48
|
> >> + >> + if `mount -t tmpfs -o size=56m none /tmp/up >/dev/null 2>&1`; then >> > > Ditto. > > Also, you can use $? to get the exit code, etc. i.e. > > if ! mount -t tmpfs -o size=56m none /tmp/up >/dev/null; then > > or: > > mount -t tmpfs -o size=56m none /tmp/up >/dev/null > if [ $? -ne 0 ]; then > rmdir /tmp/up > return 1 > fi Ok, here's the thing. if `shell-command`; then doesn't work the way you think it does. shell-command gets run, the whatever output of that command results, then gets executed *again* as a command, whose return value is then used for the conditional evaluation. Example: #!/bin/sh -x if `echo true`; then echo true else echo false fi if `echo false`; then echo true else echo false fi if `echo maybe`; then echo true else echo false fi if `cat /dev/null`; then echo true else echo false fi if `true`; then echo true else echo false fi if `false`; then echo true else echo false fi results in: ++ echo true + true + echo true true ++ echo false + false + echo false false ++ echo maybe + maybe /tmp/foo: line 15: maybe: command not found + echo false false ++ cat /dev/null + echo true true ++ true + echo true true ++ false + echo false false The last 3 cases are interesting... it shows that if result of evaluating shell-command is the empty string, then the exit-code of shell-command is used instead. This probably isn't what you're intending... and there are some interesting side effects of writing code this way. For instance, if I placed a script called "sha1sum" in your search path, and had it do: #!/bin/sh echo "/sbin/poweroff" then I could do a denial of service attack on your machine when we hit: if `sha1sum -cs $VER.tar.gz.sha1`; then sha1sum would echo the command /sbin/poweroff, which would then be run by the shell to get its exit-value... Not quite what you intended! By the way, you can put: exec >/dev/null at the top of your script, and that will make sure that none of the output (well, stdout) ever gets seen by the caller... -Philip |
|
From: Philip P. <phi...@re...> - 2008-11-11 23:09:24
|
Darrick Hartman wrote: > Kristian Kielhofner wrote: > >> On Tue, Nov 11, 2008 at 2:46 PM, Michael Keuter <mk...@we...> wrote: >> >>>> I'm running 2068 in Seattle with my Sangoma S-518 card on an net5501, >>>> using Qwest ADSL (PPPoE, alas). >>>> >>>> There are some minor issues with hardware that is known not to be on the >>>> SBC being probed, but the kernel handles the absence of the hardware >>>> correctly. >>>> >>>> My real concern at this point regarding hardware is: >>>> >>>> * not having GPIO driver >>>> * hctosys fails... is there no battery backed-up realtime clock on the >>>> net5501's? I thought there was. Having the system come up with >>>> something approximate to real-time would avoid the messages: >>>> >>>> Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >>>> (bindex=1, name=console) >>>> Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >>>> (bindex=1, name=etc) >>>> Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >>>> (bindex=1, name=etc) >>>> ... >>>> Feb 15 16:02:56 pbx daemon.info ntpd[2315]: synchronized to >>>> 69.94.125.29, stratum 2 >>>> Nov 11 10:32:58 pbx daemon.notice ntpd[2315]: time reset +875298601.985703 s >>>> ... >>>> Nov 11 10:33:03 pbx cron.err crond[1522]: time disparity of 14588310 >>>> minutes detected >>>> >>>> >>>> Darrick has said he will fine tune the linux.config file for the >>>> net5501, once that's done, we can start to try other images. >>>> >>>> Software not working at this time: >>>> >>>> * nistnet >>>> * rhino >>>> * pf_ring (kernel) >>>> >>>> It might be time to lay a label once that's all fixed and kick out >>>> tags/0.7 ... >>>> >>>> Then we can concentrate on updating Arno's firewall to 1.9.0. >>>> >>>> -Philip >>>> >>> Hi Philip, >>> >>> I found this thread regarding net5501 and GPIO: >>> >>> http://www.nabble.com/GPIO-for-net5501-under-Linux-2.6--td16408801.html >>> >>> Maybe it is useful for you. >>> >>> Michael >>> >>> >> What broke with GPIO in the latest kernel? GPIO worked on the net5501 >> with the old kernel... >> >> > > The correct GPIO driver should be enabled and working. I don't know why > Philip is saying the GPIO is not working. The rtc messages are the same > as were seen with the previous version. I haven't had a chance to boot > an image on the net5501 since we finally got things like openssl to > compile yesterday after several changes. > > I believe that post refers to an old kernel version. > > Philip may be confusing the rtc or the hardware sensors with the GPIO. > > Darrick > Well, the LED's are working... but there are additional header pins coming off the GPIO chip on the net5501 (I know, they aren't very well documented... because Soren still owes us a manual...)... I'd like to be able to use these to either read switches (like a soft-reset button) or have them drive small relays. So yes the LED's work... but the jumpers don't. We probably just need to mknod a few extra character devices... -Philip |
|
From: Darrick H. <dha...@dj...> - 2008-11-11 20:53:00
|
Kristian Kielhofner wrote: > On Tue, Nov 11, 2008 at 2:46 PM, Michael Keuter <mk...@we...> wrote: >>> I'm running 2068 in Seattle with my Sangoma S-518 card on an net5501, >>> using Qwest ADSL (PPPoE, alas). >>> >>> There are some minor issues with hardware that is known not to be on the >>> SBC being probed, but the kernel handles the absence of the hardware >>> correctly. >>> >>> My real concern at this point regarding hardware is: >>> >>> * not having GPIO driver >>> * hctosys fails... is there no battery backed-up realtime clock on the >>> net5501's? I thought there was. Having the system come up with >>> something approximate to real-time would avoid the messages: >>> >>> Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >>> (bindex=1, name=console) >>> Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >>> (bindex=1, name=etc) >>> Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >>> (bindex=1, name=etc) >>> ... >>> Feb 15 16:02:56 pbx daemon.info ntpd[2315]: synchronized to >>> 69.94.125.29, stratum 2 >>> Nov 11 10:32:58 pbx daemon.notice ntpd[2315]: time reset +875298601.985703 s >>> ... >>> Nov 11 10:33:03 pbx cron.err crond[1522]: time disparity of 14588310 >>> minutes detected >>> >>> >>> Darrick has said he will fine tune the linux.config file for the >>> net5501, once that's done, we can start to try other images. >>> >>> Software not working at this time: >>> >>> * nistnet >>> * rhino >>> * pf_ring (kernel) >>> >>> It might be time to lay a label once that's all fixed and kick out >>> tags/0.7 ... >>> >>> Then we can concentrate on updating Arno's firewall to 1.9.0. >>> >>> -Philip >> Hi Philip, >> >> I found this thread regarding net5501 and GPIO: >> >> http://www.nabble.com/GPIO-for-net5501-under-Linux-2.6--td16408801.html >> >> Maybe it is useful for you. >> >> Michael >> > > What broke with GPIO in the latest kernel? GPIO worked on the net5501 > with the old kernel... > The correct GPIO driver should be enabled and working. I don't know why Philip is saying the GPIO is not working. The rtc messages are the same as were seen with the previous version. I haven't had a chance to boot an image on the net5501 since we finally got things like openssl to compile yesterday after several changes. I believe that post refers to an old kernel version. Philip may be confusing the rtc or the hardware sensors with the GPIO. Darrick |
|
From: Kristian K. <kki...@st...> - 2008-11-11 20:40:12
|
On Tue, Nov 11, 2008 at 2:46 PM, Michael Keuter <mk...@we...> wrote: >>I'm running 2068 in Seattle with my Sangoma S-518 card on an net5501, >>using Qwest ADSL (PPPoE, alas). >> >>There are some minor issues with hardware that is known not to be on the >>SBC being probed, but the kernel handles the absence of the hardware >>correctly. >> >>My real concern at this point regarding hardware is: >> >>* not having GPIO driver >>* hctosys fails... is there no battery backed-up realtime clock on the >>net5501's? I thought there was. Having the system come up with >>something approximate to real-time would avoid the messages: >> >>Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >>(bindex=1, name=console) >>Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >>(bindex=1, name=etc) >>Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >>(bindex=1, name=etc) >>... >>Feb 15 16:02:56 pbx daemon.info ntpd[2315]: synchronized to >>69.94.125.29, stratum 2 >>Nov 11 10:32:58 pbx daemon.notice ntpd[2315]: time reset +875298601.985703 s >>... >>Nov 11 10:33:03 pbx cron.err crond[1522]: time disparity of 14588310 >>minutes detected >> >> >>Darrick has said he will fine tune the linux.config file for the >>net5501, once that's done, we can start to try other images. >> >>Software not working at this time: >> >>* nistnet >>* rhino >>* pf_ring (kernel) >> >>It might be time to lay a label once that's all fixed and kick out >>tags/0.7 ... >> >>Then we can concentrate on updating Arno's firewall to 1.9.0. >> >>-Philip > > Hi Philip, > > I found this thread regarding net5501 and GPIO: > > http://www.nabble.com/GPIO-for-net5501-under-Linux-2.6--td16408801.html > > Maybe it is useful for you. > > Michael > What broke with GPIO in the latest kernel? GPIO worked on the net5501 with the old kernel... -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com |
|
From: Michael K. <mk...@we...> - 2008-11-11 19:47:08
|
>I'm running 2068 in Seattle with my Sangoma S-518 card on an net5501, >using Qwest ADSL (PPPoE, alas). > >There are some minor issues with hardware that is known not to be on the >SBC being probed, but the kernel handles the absence of the hardware >correctly. > >My real concern at this point regarding hardware is: > >* not having GPIO driver >* hctosys fails... is there no battery backed-up realtime clock on the >net5501's? I thought there was. Having the system come up with >something approximate to real-time would avoid the messages: > >Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >(bindex=1, name=console) >Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >(bindex=1, name=etc) >Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime >(bindex=1, name=etc) >... >Feb 15 16:02:56 pbx daemon.info ntpd[2315]: synchronized to >69.94.125.29, stratum 2 >Nov 11 10:32:58 pbx daemon.notice ntpd[2315]: time reset +875298601.985703 s >... >Nov 11 10:33:03 pbx cron.err crond[1522]: time disparity of 14588310 >minutes detected > > >Darrick has said he will fine tune the linux.config file for the >net5501, once that's done, we can start to try other images. > >Software not working at this time: > >* nistnet >* rhino >* pf_ring (kernel) > >It might be time to lay a label once that's all fixed and kick out >tags/0.7 ... > >Then we can concentrate on updating Arno's firewall to 1.9.0. > >-Philip Hi Philip, I found this thread regarding net5501 and GPIO: http://www.nabble.com/GPIO-for-net5501-under-Linux-2.6--td16408801.html Maybe it is useful for you. Michael -- Email: mailto:mk...@we... |
|
From: Philip P. <phi...@re...> - 2008-11-11 18:44:09
|
I'm running 2068 in Seattle with my Sangoma S-518 card on an net5501, using Qwest ADSL (PPPoE, alas). There are some minor issues with hardware that is known not to be on the SBC being probed, but the kernel handles the absence of the hardware correctly. My real concern at this point regarding hardware is: * not having GPIO driver * hctosys fails... is there no battery backed-up realtime clock on the net5501's? I thought there was. Having the system come up with something approximate to real-time would avoid the messages: Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime (bindex=1, name=console) Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime (bindex=1, name=etc) Feb 15 16:02:35 pbx user.info kernel: unionfs: new lower inode mtime (bindex=1, name=etc) ... Feb 15 16:02:56 pbx daemon.info ntpd[2315]: synchronized to 69.94.125.29, stratum 2 Nov 11 10:32:58 pbx daemon.notice ntpd[2315]: time reset +875298601.985703 s ... Nov 11 10:33:03 pbx cron.err crond[1522]: time disparity of 14588310 minutes detected Darrick has said he will fine tune the linux.config file for the net5501, once that's done, we can start to try other images. Software not working at this time: * nistnet * rhino * pf_ring (kernel) It might be time to lay a label once that's all fixed and kick out tags/0.7 ... Then we can concentrate on updating Arno's firewall to 1.9.0. -Philip |
|
From: Darrick H. <dha...@dj...> - 2008-11-11 03:39:28
|
The acpi stuff needs to be disabled. I'll try to do that tonight yet. Darrick On Mon, 10 Nov 2008 21:04:58 -0600, Philip Prindeville wrote: > I'm running 2067 on a test box right now with no major issues. > > Looking at dmesg, I see: > > Sep 25 10:14:59 pbx user.info kernel: DMI not present or invalid. > Sep 25 10:14:59 pbx user.warn kernel: ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126] > ... > Sep 25 10:14:59 pbx user.info kernel: ide_setup: ide=nodma : Prevented DMA > Sep 25 10:14:59 pbx user.warn kernel: -- OBSOLETE OPTION, WILL BE REMOVED SOON! > ... > Sep 25 10:14:59 pbx user.err kernel: geode: Couldn't initialize 'geode-pms' > Sep 25 10:14:59 pbx user.err kernel: geode: Couldn't initialize 'geode-acpi' > ... > Sep 25 10:14:59 pbx user.info kernel: No dock devices found. > ... > Sep 25 10:14:59 pbx user.info kernel: ACPI: Interprete> Sep 25 10:14:59 pbx user.info kernel: Linux Plug and Play Support v0.97 (c) Adam Belay > Sep 25 10:14:59 pbx user.info kernel: pnp: PnP ACPI: disabled > Sep 25 10:14:59 pbx user.info kernel: PnPBIOS: Scanning system for PnP BIOS support... > Sep 25 10:14:59 pbx user.info kernel: PnPBIOS: PnP BIOS support was not detected. > ... > Sep 25 10:14:59 pbx user.warn kernel: Driver 'sd' needs updating - please use bus_type methods > ... > Sep 25 10:14:59 pbx user.warn kernel: drivers/rtc/hctosys.c: unable to open rtc device (rtc) > ... > Sep 25 10:15:00 pbx user.info kernel: pc87360: Device 0x09 not activated > ... > > > > The rtc message pre-existed... though that's always worried me. Why > doesn't that work? Doesn't the net5501 have a CMOS clock onboard? > > Darrick or Kris: can you poke around the net5501 configuration? > > Thanks, > > -Philip > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ________________________> Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... -- Darrick Hartman DJH Solutions, LLC http://www.djhsolutions.com 920.901.3113 M 920.547.4535 O |
|
From: Philip P. <phi...@re...> - 2008-11-11 03:05:05
|
I'm running 2067 on a test box right now with no major issues. Looking at dmesg, I see: Sep 25 10:14:59 pbx user.info kernel: DMI not present or invalid. Sep 25 10:14:59 pbx user.warn kernel: ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126] ... Sep 25 10:14:59 pbx user.info kernel: ide_setup: ide=nodma : Prevented DMA Sep 25 10:14:59 pbx user.warn kernel: -- OBSOLETE OPTION, WILL BE REMOVED SOON! ... Sep 25 10:14:59 pbx user.err kernel: geode: Couldn't initialize 'geode-pms' Sep 25 10:14:59 pbx user.err kernel: geode: Couldn't initialize 'geode-acpi' ... Sep 25 10:14:59 pbx user.info kernel: No dock devices found. ... Sep 25 10:14:59 pbx user.info kernel: ACPI: Interpreter disabled. Sep 25 10:14:59 pbx user.info kernel: Linux Plug and Play Support v0.97 (c) Adam Belay Sep 25 10:14:59 pbx user.info kernel: pnp: PnP ACPI: disabled Sep 25 10:14:59 pbx user.info kernel: PnPBIOS: Scanning system for PnP BIOS support... Sep 25 10:14:59 pbx user.info kernel: PnPBIOS: PnP BIOS support was not detected. ... Sep 25 10:14:59 pbx user.warn kernel: Driver 'sd' needs updating - please use bus_type methods ... Sep 25 10:14:59 pbx user.warn kernel: drivers/rtc/hctosys.c: unable to open rtc device (rtc) ... Sep 25 10:15:00 pbx user.info kernel: pc87360: Device 0x09 not activated ... The rtc message pre-existed... though that's always worried me. Why doesn't that work? Doesn't the net5501 have a CMOS clock onboard? Darrick or Kris: can you poke around the net5501 configuration? Thanks, -Philip |
|
From: Darrick H. <dha...@dj...> - 2008-11-11 00:15:57
|
Philip, I reverted the rhino changes. Darrick Philip Prindeville wrote: > Bugger. Well, those changes weren't supposed to go in along with the > linux.mk change. Forgot to scope my commit. > > The changes for the most part are tested and working (except for rhino, > which continues to be broken). > > Tried to get bash to have job control, but that's still not working. > > Bash pretty much works as before. > > > ppr...@us... wrote: >> Revision: 2066 >> http://astlinux.svn.sourceforge.net/astlinux/?rev=2066&view=rev >> Author: pprindeville >> Date: 2008-11-10 23:07:28 +0000 (Mon, 10 Nov 2008) >> >> Log Message: >> ----------- >> Not using -z flag to tar or calling zcat on archive >> >> Modified Paths: >> -------------- >> trunk/package/bash/bash.mk >> trunk/package/flex/flex.mk >> trunk/package/rhino/rhino.mk >> trunk/target/device/net5501/linux.mk >> >> Removed Paths: >> ------------- >> trunk/package/bash/bash30-001 >> trunk/package/bash/bash30-002 >> trunk/package/bash/bash30-003 >> trunk/package/bash/bash30-004 >> trunk/package/bash/bash30-005 >> trunk/package/bash/bash30-006 >> trunk/package/bash/bash30-007 >> trunk/package/bash/bash30-008 >> trunk/package/bash/bash30-009 >> trunk/package/bash/bash30-010 >> trunk/package/bash/bash30-011 >> trunk/package/bash/bash30-012 >> trunk/package/bash/bash30-013 >> trunk/package/bash/bash30-014 >> trunk/package/bash/bash30-015 >> trunk/package/bash/bash30-016 >> trunk/package/bash/bash30-050-signames >> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Philip P. <phi...@re...> - 2008-11-10 23:53:57
|
Bugger. Well, those changes weren't supposed to go in along with the linux.mk change. Forgot to scope my commit. The changes for the most part are tested and working (except for rhino, which continues to be broken). Tried to get bash to have job control, but that's still not working. Bash pretty much works as before. ppr...@us... wrote: > Revision: 2066 > http://astlinux.svn.sourceforge.net/astlinux/?rev=2066&view=rev > Author: pprindeville > Date: 2008-11-10 23:07:28 +0000 (Mon, 10 Nov 2008) > > Log Message: > ----------- > Not using -z flag to tar or calling zcat on archive > > Modified Paths: > -------------- > trunk/package/bash/bash.mk > trunk/package/flex/flex.mk > trunk/package/rhino/rhino.mk > trunk/target/device/net5501/linux.mk > > Removed Paths: > ------------- > trunk/package/bash/bash30-001 > trunk/package/bash/bash30-002 > trunk/package/bash/bash30-003 > trunk/package/bash/bash30-004 > trunk/package/bash/bash30-005 > trunk/package/bash/bash30-006 > trunk/package/bash/bash30-007 > trunk/package/bash/bash30-008 > trunk/package/bash/bash30-009 > trunk/package/bash/bash30-010 > trunk/package/bash/bash30-011 > trunk/package/bash/bash30-012 > trunk/package/bash/bash30-013 > trunk/package/bash/bash30-014 > trunk/package/bash/bash30-015 > trunk/package/bash/bash30-016 > trunk/package/bash/bash30-050-signames > |
|
From: Philip P. <phi...@re...> - 2008-11-10 23:08:16
|
Darrick Hartman wrote: > Philip Prindeville wrote: > >> Kristian Kielhofner wrote: >> >>> On Fri, Nov 7, 2008 at 5:34 PM, Philip Prindeville >>> <phi...@re...> wrote: >>> >>> >>>> That's right. >>>> >>>> We've got a fair amount of churn on some files (like the OCF patches and >>>> the net5501/linux.config file) and what that to stabilize before we >>>> figure out what really got changed. >>>> >>>> >>>> >>>> >>> So what is the deal with OCF... >>> >>> It looks like we've got a minimal OCF patch in device/kernel-patches. >>> >>> We also (attempt) to untar an OCF tarball into the kernel source. >>> >>> Why not just apply a straight OCF patch? Why the untar? This was >>> brought to my attention because as-is, it's broken either way. We're >>> not currently passing "z" to the tar command line to pipe it through >>> gzip first. That got me to thinking - what *should* we be doing here? >>> >>> >>> >> OCF isn't part of the kernel, it comes as a separate tarball. It gets >> unpacked into the kernel (at least until it becomes part of the kernel >> and we can retire the tarball and makefile-glue). >> >> The patch gets applied is a minor patch to the kernel Kconfig and >> Makefiles to include the tarballed directories into the build process... >> plus a kind of gross patch for driver/char/random.h... which is >> necessary for FIPS RNG conformance testing (i.e. that the RNG has to be >> sufficiently R to be strong). >> >> I'll commit a fix for two things (the compression included) shortly... >> > > Kris already committed the fix. > > Darrick > Sigh. Too late. Anyone know why sourceforge is taking 40+ minutes to send the emails out about commits? -Philip |
|
From: Darrick H. <dha...@dj...> - 2008-11-10 23:06:54
|
Philip Prindeville wrote: > Kristian Kielhofner wrote: >> On Fri, Nov 7, 2008 at 5:34 PM, Philip Prindeville >> <phi...@re...> wrote: >> >>> That's right. >>> >>> We've got a fair amount of churn on some files (like the OCF patches and >>> the net5501/linux.config file) and what that to stabilize before we >>> figure out what really got changed. >>> >>> >>> >> So what is the deal with OCF... >> >> It looks like we've got a minimal OCF patch in device/kernel-patches. >> >> We also (attempt) to untar an OCF tarball into the kernel source. >> >> Why not just apply a straight OCF patch? Why the untar? This was >> brought to my attention because as-is, it's broken either way. We're >> not currently passing "z" to the tar command line to pipe it through >> gzip first. That got me to thinking - what *should* we be doing here? >> >> > > OCF isn't part of the kernel, it comes as a separate tarball. It gets > unpacked into the kernel (at least until it becomes part of the kernel > and we can retire the tarball and makefile-glue). > > The patch gets applied is a minor patch to the kernel Kconfig and > Makefiles to include the tarballed directories into the build process... > plus a kind of gross patch for driver/char/random.h... which is > necessary for FIPS RNG conformance testing (i.e. that the RNG has to be > sufficiently R to be strong). > > I'll commit a fix for two things (the compression included) shortly... Kris already committed the fix. Darrick |
|
From: Philip P. <phi...@re...> - 2008-11-10 23:00:44
|
Kristian Kielhofner wrote: > On Fri, Nov 7, 2008 at 5:34 PM, Philip Prindeville > <phi...@re...> wrote: > >> That's right. >> >> We've got a fair amount of churn on some files (like the OCF patches and >> the net5501/linux.config file) and what that to stabilize before we >> figure out what really got changed. >> >> >> > > So what is the deal with OCF... > > It looks like we've got a minimal OCF patch in device/kernel-patches. > > We also (attempt) to untar an OCF tarball into the kernel source. > > Why not just apply a straight OCF patch? Why the untar? This was > brought to my attention because as-is, it's broken either way. We're > not currently passing "z" to the tar command line to pipe it through > gzip first. That got me to thinking - what *should* we be doing here? > > OCF isn't part of the kernel, it comes as a separate tarball. It gets unpacked into the kernel (at least until it becomes part of the kernel and we can retire the tarball and makefile-glue). The patch gets applied is a minor patch to the kernel Kconfig and Makefiles to include the tarballed directories into the build process... plus a kind of gross patch for driver/char/random.h... which is necessary for FIPS RNG conformance testing (i.e. that the RNG has to be sufficiently R to be strong). I'll commit a fix for two things (the compression included) shortly... -Philip |
|
From: Kristian K. <kki...@st...> - 2008-11-10 22:22:45
|
On Fri, Nov 7, 2008 at 5:34 PM, Philip Prindeville <phi...@re...> wrote: > That's right. > > We've got a fair amount of churn on some files (like the OCF patches and > the net5501/linux.config file) and what that to stabilize before we > figure out what really got changed. > > So what is the deal with OCF... It looks like we've got a minimal OCF patch in device/kernel-patches. We also (attempt) to untar an OCF tarball into the kernel source. Why not just apply a straight OCF patch? Why the untar? This was brought to my attention because as-is, it's broken either way. We're not currently passing "z" to the tar command line to pipe it through gzip first. That got me to thinking - what *should* we be doing here? -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com |
