Package: lnx-bbc Priority: wishlist We should have better NTFS support -- whatever kind of NTFS support is currently possible. We should package the ntfsprogs, for a start. -- -- Seth David Schoen <schoen <at> loyalty.org> | Reading is a right, not a feature! http://www.loyalty.org/~schoen/ | -- Kathryn Myronuk http://vitanuova.loyalty.org/ |
Your message dated Fri, 31 Jan 2003 16:32:13 -0800 with message-id <20030201003213.GF19335 <at> zork.net> and subject line Nope has caused the attached bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Nick Moffitt (administrator, LNX-BBC bugs database) -------------------------------------- Received: (at submit) by bugs.lnx-bbc.org; 24 Dec 2002 18:20:58 +0000 From schoen <at> zork.net Tue Dec 24 10:20:58 2002 Received: from zork.zork.net ([66.92.188.166] ident=mail) by gar.lnx-bbc.org with esmtp (Exim 3.36 #1 (Debian)) id 18Qtfl-0003Re-00 for <submit <at> bugs.lnx-bbc.org>; Tue, 24 Dec 2002 10:20:58 -0800 Received: from schoen by zork.zork.net with local (Exim 3.35 #1 (Debian)) id 18QtgE-0004TP-00; Tue, 24 Dec 2002 10:21:26 -0800 Date: Tue, 24 Dec 2002 10:21:26 -0800 From: Seth David Schoen <schoen <at> loyalty.org> To: submit <at> bugs.lnx-bbc.org Subject: CDDA track Message-ID: <20021224182126.GM32746 <at> zork.net>(Continue reading)
Package: linux Severity: grave On LNX-BBC 2.0 rc1, I can't loopback mount an ISO9660 filesystem from userspace after booting. -- -- Seth David Schoen <schoen <at> loyalty.org> | Reading is a right, not a feature! http://www.loyalty.org/~schoen/ | -- Kathryn Myronuk http://vitanuova.loyalty.org/ |
Just now Seth David Schoen made 15 LEDs in my apartment flash with this: > Package: linux > Severity: grave > > On LNX-BBC 2.0 rc1, I can't loopback mount an ISO9660 filesystem from > userspace after booting. Using which method? -- -- --< ((\))< >----< inkblot <at> movealong.org >----< http://www.movealong.org/ >-- American currency is neither red, white, nor blue. pub 1024D/05A058E0 2002-03-07 Nate Riffe (06-Mar-2002) <inkblot <at> movealong.org> Key fingerprint = 0DAC F5CB D182 3165 D757 C466 CD42 12A8 05A0 58E0
Nate Riffe writes: > Just now Seth David Schoen made 15 LEDs in my apartment flash with this: > > Package: linux > > Severity: grave > > > > On LNX-BBC 2.0 rc1, I can't loopback mount an ISO9660 filesystem from > > userspace after booting. mount -o ro -o loop foo.iso /mnt/rw/foo -- -- Seth David Schoen <schoen <at> loyalty.org> | Reading is a right, not a feature! http://www.loyalty.org/~schoen/ | -- Kathryn Myronuk http://vitanuova.loyalty.org/ |
Package: lnx-bbc When you build on gar, you get an image which is around 1,000,000 bytes smaller than the image you get by building on a chroot on garson from exactly the same source tree. We would like the image to be as small as possible, so it would be good to understand exactly why this happens, and how to control the build process to get it to produce the smallest possible image. -- -- Seth David Schoen <schoen <at> loyalty.org> | Reading is a right, not a feature! http://www.loyalty.org/~schoen/ | -- Kathryn Myronuk http://vitanuova.loyalty.org/ |
We've observed that the build environment and build host have a substantial effect on the size of the generated ISO image -- producing variations up to a million bytes! For example, the nightly builds produced by gar are around 48000000 bytes, where the result of building on garson in a chroot with exactly the same source tree is around 49000000 bytes, or around a 2% overall difference. Nick and I looked at the individual binaries during the meeting today and discovered that the chroot-built binaries on garson are typically substantially larger than the equivalent binaries built on the native environment on gar. (Interestingly, some binaries, such as openssl, are exactly the same size, down to the byte. Most binaries, though, appear to differ in size by a few percent.) One hypothesis about this is that it has to do with the -mcpu flags which are being passed to the compiler. Some configure scripts or Makefiles seem to run "arch" and then pass the equivalent of -mcpu=$(shell arch) to gcc, causing it to generate code which is optimized for that particular CPU. (As Nick has pointed out, there is also -march, which generates code which is optimized for that particular CPU and might be incompatible with other CPUs. -march is used by at least one upstream packages, and we ought to purge it very aggressively.) The net result, in any case, is definitely individual binaries which are different sizes depending on which machine they were built on. The -mcpu discrepancy seems to be a plausible source of these differences. I ran a compile of a randomly chosen small program with -Os -mcpu=i386 and again with the same source file and -Os -mcpu=i686 and immediately saw a difference of several hundred bytes (about 2% of(Continue reading)
Your message dated Sat, 1 Feb 2003 22:06:26 -0800
with message-id <20030202060626.GA32306 <at> zork.net>
and subject line Thanks, Nick
has caused the attached bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Nick Moffitt
(administrator, LNX-BBC bugs database)
--------------------------------------
Received: (at submit) by bugs.lnx-bbc.org; 26 Jan 2003 16:37:30 +0000
From frey <at> attbi.com Sun Jan 26 08:37:30 2003
Received: from rwcrmhc52.attbi.com ([216.148.227.88])
by gar.lnx-bbc.org with esmtp (Exim 3.36 #1 (Debian))
id 18cpmg-0001ld-00
for <submit <at> bugs.lnx-bbc.org>; Sun, 26 Jan 2003 08:37:30 -0800
Received: from attbi.com (h00207813df81.ne.client2.attbi.com[24.128.152.198])
by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP
id <20030126163711052007lfase>; Sun, 26 Jan 2003 16:37:12 +0000
Message-ID: <3E340ECA.4000909 <at> attbi.com>
Date: Sun, 26 Jan 2003 11:37:30 -0500
From: "Michael H. Frey" <frey <at> attbi.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
(Continue reading)What's odd about this is that uname -m gives exactly the same output on gar and garson -- including in the chroot. Maybe that's not the whole story. It is pretty clear that they do build binaries of different sizes for some reason. -- -- Seth David Schoen <schoen <at> loyalty.org> | Reading is a right, not a feature! http://www.loyalty.org/~schoen/ | -- Kathryn Myronuk http://vitanuova.loyalty.org/ |
Seth David Schoen writes: > What's odd about this is that uname -m gives exactly the same output > on gar and garson -- including in the chroot. Maybe that's not the > whole story. > > It is pretty clear that they do build binaries of different sizes for > some reason. OK, Inside the chroot: schoen <at> requiem:~/gar/utils/util-linux/work/util-linux-2.11u/rescuept$ gcc --vers ion 2.95.4 schoen <at> requiem:~/gar/utils/util-linux/work/util-linux-2.11u/rescuept$ gcc -Os -o rescuept rescuept.c /tmp/ccIsLHj1.o: In function `read_sectors': /tmp/ccIsLHj1.o(.text+0x23): the `llseek' function may be dangerous; use `lseek64' instead. schoen <at> requiem:~/gar/utils/util-linux/work/util-linux-2.11u/rescuept$ ls -l resc uept -rwxr-xr-x 1 schoen schoen 11397 Feb 2 07:55 rescuept schoen <at> requiem:~/gar/utils/util-linux/work/util-linux-2.11u/rescuept$ gcc -o rescuept rescuept.c /tmp/ccaqFhSp.o: In function `read_sectors': /tmp/ccaqFhSp.o(.text+0x3b): the `llseek' function may be dangerous; use `lseek64' instead. schoen <at> requiem:~/gar/utils/util-linux/work/util-linux-2.11u/rescuept$ ls -l resc uept -rwxr-xr-x 1 schoen schoen 13319 Feb 2 07:55 rescuept schoen <at> requiem:~/gar/utils/util-linux/work/util-linux-2.11u/rescuept$ Outside the chroot: schoen <at> requiem:~/gar/utils/util-linux/work/util-linux-2.11u/rescuept$ gcc --version(Continue reading)
RSS Feed1 | |
|---|---|
4 | |
3 | |
2 | |
1 | |
1 | |
4 | |
1 | |
1 | |
2 | |
2 | |
12 | |
68 | |
3 | |
9 | |
20 | |
11 | |
153 | |
111 | |
39 | |
69 | |
300 | |
117 | |
152 | |
26 |
