On 4/8/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 08, 2006 at 06:33:39PM +0200, M.Canales.es wrote:
> > In that case I would suggest 6.6 Creating Essential Symlinks (and files). I
> > think that could fit better here.
>
> Well, if we're changing that page from just Essential Symli
El Sábado, 8 de Abril de 2006 18:54, Jeremy Huntwork escribió:
> Well, if we're changing that page from just Essential Symlinks to
> Essential Symlinks and Files, then we might as well merge that page with
> 6.7 because, in my mind, 6.7 as it is really could be renamed to
> 'Creating Essential Fil
On Sat, Apr 08, 2006 at 06:33:39PM +0200, M.Canales.es wrote:
> In that case I would suggest 6.6 Creating Essential Symlinks (and files). I
> think that could fit better here.
Well, if we're changing that page from just Essential Symlinks to
Essential Symlinks and Files, then we might as well mer
El Sábado, 8 de Abril de 2006 18:24, Jeremy Huntwork escribió:
> My reasoning is that 1) /etc/mtab isn't really anything to do with the
> other kernfs mounts, 2) we already create /etc in 6.5 "Creating
> Directories" and that fits there - there's no real need to create /etc
> any earlier 3) by sec
On Fri, Apr 07, 2006 at 01:37:07PM -0700, Dan Nicholson wrote:
> I think it should go right with the mount commands so there is no
> confusion. Also, we don't know whether another package depends upon
> an mtab file being present. To me, it's safest to add
>
> mkdir -pv ${LFS}/etc
> touch ${LFS}
On Fri, Apr 07, 2006 at 01:37:07PM -0700, Dan Nicholson wrote:
> I think it should go right with the mount commands so there is no
> confusion. Also, we don't know whether another package depends upon
> an mtab file being present. To me, it's safest to add
>
> mkdir -pv ${LFS}/etc
> touch ${LFS}
On 4/7/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Viernes, 7 de Abril de 2006 22:27, Dan Nicholson escribió:
>
> > Yes, I get the failures without /etc/mtab. That's the issue.
>
> Due that in udev_update no mounts are done inside the chroot, /etc/mtab isn't
> created.
>
> I think that we sho
El Viernes, 7 de Abril de 2006 22:27, Dan Nicholson escribió:
> Yes, I get the failures without /etc/mtab. That's the issue.
Due that in udev_update no mounts are done inside the chroot, /etc/mtab isn't
created.
I think that we should to add the "touch /etc/mtab" in chapter06/e2fsprogs.xml
ju
On 4/7/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Viernes, 7 de Abril de 2006 22:08, M.Canales.es escribió:
>
> > After the removal of /etc/mtab, the test failures are here againg.
>
> More news:
>
> A plain "touch $LFS/etc/mtab" allow to pass successfully all e2fsprogs test.
Yes, I get the
El Viernes, 7 de Abril de 2006 22:08, M.Canales.es escribió:
> After the removal of /etc/mtab, the test failures are here againg.
More news:
A plain "touch $LFS/etc/mtab" allow to pass successfully all e2fsprogs test.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfro
On 4/7/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Viernes, 7 de Abril de 2006 22:07, Dan Nicholson escribió:
>
> > I just built e2fsprogs in chroot using mount --bind and no other
> > modifications except that it's building on top of a full system. No
> > test failures:
>
> Do you have an $L
El Viernes, 7 de Abril de 2006 22:07, Dan Nicholson escribió:
> I just built e2fsprogs in chroot using mount --bind and no other
> modifications except that it's building on top of a full system. No
> test failures:
Do you have an $LFS/etc/mtab file?
--
Manuel Canales Esparcia
Usuario de LFS n
El Viernes, 7 de Abril de 2006 21:43, Archaic escribió:
> However, for size recording, my script does one thing in chroot to make
> / appear in /etc/mtab:
>
> mount -f -t $fs_type /dev/$partition /
>
> Maybe that's why it works for me?
Bingo!
When I made the umount of /dev and remount all ker
On 4/7/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
>
> Confirmed :-/
>
> Using mount -bind:
>
> 2 tests succeeded 79 tests failed
>
> Using the old method to populate $LFS/dev:
>
> 81 tests succeeded 0 tests failed
I just built e2fsprogs in chroot using mount --bind and no other
modifications exce
On Fri, Apr 07, 2006 at 10:26:10AM -0700, Dan Nicholson wrote:
>
> This may have to do with mount --bind. I can't think of any other
> reasons for it. Definitely needs investigation. Could you post
> anything that sticks out about these failures?
For some reason, I cannot duplicate that proble
M.Canales.es wrote:
> Well, all that is beyond my capabilities. Real developers should to
> try to solve this issue.
Not that I'm necessarily a "real developer", but I do understand C, so
I'll see if I can replicate the failing environment here and do some
tests. I have e2fsprogs, but the rest (t
El Viernes, 7 de Abril de 2006 21:05, Bryan Kadzban escribió:
> The rest of the function is a bit hairy though. Probably the best way
> to figure out what exactly it's complaining about is to set the DEBUG
> preprocessor define to something other than zero; this should be doable
> if you cd into
M.Canales.es wrote:
> + ext2fs_check_if_mount: No such file or directory while determining
> whether ./test.img is mounted.
Hmm. There are a few different places where that message appears in the
e2fsprogs source. Most of the tests seem to run e2fsck on an image,
though, so it's probably coming
El Viernes, 7 de Abril de 2006 20:36, Bryan Kadzban escribió:
> Any idea which tests succeeded / failed?
e_icount_normal: inode counting abstraction optimized for storing inode
counts: ok
e_icount_opt: inode counting abstraction optimized for counting: ok
> What happens if you build with the n
El Viernes, 7 de Abril de 2006 20:20, M.Canales.es escribió:
> I have keeped both build trees, if you need some info from them.
Diffing the build trees all dfferences are in the build/test/* files.
All files on that drectory for the "mount -bind" build have ths additional
line:
+ ext2fs_check
M.Canales.es wrote:
> Confirmed :-/
>
> Using mount -bind:
>
> 2 tests succeeded 79 tests failed
>
> Using the old method to populate $LFS/dev:
>
> 81 tests succeeded 0 tests failed
>
> The build logs don't show differences beyond "ok" or "failed" for
> each test.
>
> I have keeped both build
El Viernes, 7 de Abril de 2006 20:06, Dan Nicholson escribió:
> On 4/7/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> > I have yet all the kernel filesystems mounted. I will do now a new
> > E2fsprogs build ith mount -bind. After that i will to umount /dev and
> > mount it again like is done in tru
On 4/7/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Viernes, 7 de Abril de 2006 19:51, Dan Nicholson escribió:
>
> >
> > Unfortunately, there's not a lot of info there. Do you still have the
> > source directory? How about, now that the base system is installed,
> > try to rebuild e2fsprogs a
El Viernes, 7 de Abril de 2006 19:51, Dan Nicholson escribió:
>
> Unfortunately, there's not a lot of info there. Do you still have the
> source directory? How about, now that the base system is installed,
> try to rebuild e2fsprogs and see if the tests still fail.
I have yet all the kernel fil
On 4/7/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
>
> > This may have to do with mount --bind. I can't think of any other
> > reasons for it. Definitely needs investigation. Could you post
> > anything that sticks out about these failures?
>
> Attached the full E2fsprogs build log.
Unfortunate
El Viernes, 7 de Abril de 2006 19:26, Dan Nicholson escribió:
> Out of curiosity, what kind of hardware do you have? I've been
> getting three error here using an Athlon-XP for a while now. I like
> to think these are processor specific, but I haven't really
> investigated.
An Intel(R) Pentium(
On 4/7/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
>
> Chapter 06 GCC test suite summary:
>
> === gcc Summary ===
>
> # of expected passes 35544
> # of unexpected successes 3
> # of expected failures 92
> # of untested testcases 28
> # of unsupported tests 326
> /sources/gcc-build/gcc/xgcc v
El Jueves, 6 de Abril de 2006 22:37, Archaic escribió:
> On Thu, Apr 06, 2006 at 10:27:23PM +0200, M.Canales.es wrote:
> > The build will take some hours on my system, then the commit will be made
> > tomorrow if there is no build issues.
>
> Sounds good, Manuel. Thanks for all the help! :)
Build
On Thu, Apr 06, 2006 at 10:27:23PM +0200, M.Canales.es wrote:
>
> The build will take some hours on my system, then the commit will be made
> tomorrow if there is no build issues.
Sounds good, Manuel. Thanks for all the help! :)
--
Archaic
Want control, education, and security from your opera
El Jueves, 6 de Abril de 2006 22:16, Archaic escribió:
>
> You sure are in a hurry today Manuel. :) Have you actually built a
> system according to the proposed changes? I would suggest a run of
> jhalfs on your local copy before committing.
I'm downloading now the last updated packages.
The bui
On Thu, Apr 06, 2006 at 09:17:13PM +0200, M.Canales.es wrote:
>
> OK. I will do the commit in a hour if there is no objections from others
> folks.
You sure are in a hurry today Manuel. :) Have you actually built a
system according to the proposed changes? I would suggest a run of
jhalfs on your
El Jueves, 6 de Abril de 2006 21:00, Jeremy Huntwork escribió:
> Yes, I see what you were thinking. I misunderstood your intentions
> before. Well, if it makes it easier to merge udev_update back to trunk,
> then I'd say go for it.
OK. I will do the commit in a hour if there is no objections from
On 4/6/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> As for ICA testing, as Archaic said, Dan's already testing those
> changes. In any case, I can't see how the udev changes would affect ICA,
> but you never know.
The only thing to really check is that `mount --bind' doesn't upset
anything.
On 4/6/06, Archaic <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 06, 2006 at 08:14:33PM +0200, M.Canales.es wrote:
> >
> > Do you agree with making I that commit?
>
> I concur with Jeremy. Also, Dan is doing an alpha-style udev_update
> build now to see if it passes ICA. I'd like to hold off until he is
M.Canales.es wrote:
Are the alphabetical changes suitables for the udev_update branch? Want we to
test udev_update+alphatetical before to do the final merge?
If yes. we should to do that commit first.
If not, we can try to merge udev_update to trunk on their own.
Yes, I see what you were
El Jueves, 6 de Abril de 2006 20:31, Jeremy Huntwork escribió:
> Oh. I thought you were doing it the other way. Since alpha is in trunk
> now, I you were going to merge all the changes to the udev_branch since
> it split from trunk back to trunk. This agrees with the method in the
> subversion doc
M.Canales.es wrote:
El Jueves, 6 de Abril de 2006 20:19, Jeremy Huntwork escribió:
Well, any chance you can attach a diff here first? I'm just curious
about what gets changed...
Attached.
Oh. I thought you were doing it the other way. Since alpha is in trunk
now, I you were going to merge
El Jueves, 6 de Abril de 2006 20:19, Jeremy Huntwork escribió:
> Well, any chance you can attach a diff here first? I'm just curious
> about what gets changed...
Attached.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escom
On Thu, Apr 06, 2006 at 08:14:33PM +0200, M.Canales.es wrote:
>
> Do you agree with making I that commit?
I concur with Jeremy. Also, Dan is doing an alpha-style udev_update
build now to see if it passes ICA. I'd like to hold off until he is
done.
--
Archaic
Want control, education, and securi
M.Canales.es wrote:
Making that commit could allow us to have a cleanest diff against trunk and to
do ICA test on the udev_update branch before do the final merge.
Do you agree with making I that commit?
Well, any chance you can attach a diff here first? I'm just curious
about what gets cha
El Jueves, 6 de Abril de 2006 19:46, M.Canales.es escribió:
> El Jueves, 6 de Abril de 2006 19:42, Jeremy Huntwork escribió:
> > I'm sure Archaic wouldn't mind if you started on seeing what would need
> > to happen to merge udev in now (perhaps even create a diff?) I think its
> > wise to leave spa
El Jueves, 6 de Abril de 2006 19:42, Jeremy Huntwork escribió:
> I'm sure Archaic wouldn't mind if you started on seeing what would need
> to happen to merge udev in now (perhaps even create a diff?) I think its
> wise to leave space of a week for testing between merges, though.
Generating the di
M.Canales.es wrote:
El Jueves, 6 de Abril de 2006 19:28, Jeremy Huntwork escribió:
I'm merging alpha as we speak. Archaic and I have planned to do
udev_update next week, if no objections are made.
No objections in my end ;-)
lol. That just sounds funny. But I think I know what you meant. :
El Jueves, 6 de Abril de 2006 19:28, Jeremy Huntwork escribió:
> I'm merging alpha as we speak. Archaic and I have planned to do
> udev_update next week, if no objections are made.
No objections in my end ;-)
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.or
M.Canales.es wrote:
The merge will be not traumatic. I can to merge both now if you like (and if I
no lost my ADSL connexion again)
I'm merging alpha as we speak. Archaic and I have planned to do
udev_update next week, if no objections are made.
--
JH
--
http://linuxfromscratch.org/mailman
El Martes, 4 de Abril de 2006 20:30, Archaic escribió:
> On Tue, Apr 04, 2006 at 12:25:22PM -0600, Jeremy Herbison wrote:
> > Why not merge alpha into udev_branch, then just replace svn with
> > udev_branch?
>
> It doesn't gain us anything, plus it keeps us from being able to revert
> either of the
On Tue, Apr 04, 2006 at 12:25:22PM -0600, Jeremy Herbison wrote:
> >
> Why not merge alpha into udev_branch, then just replace svn with
> udev_branch?
It doesn't gain us anything, plus it keeps us from being able to revert
either of the 2 unique changes in trunk itself (which is where reverting
w
>
> Dan Nicholson wrote:
> > To finish this thought, alpha will touch a lot of files once Chris'
> > dependency info goes in. The build commands are essentially the same
> > except one change in perl. However, I think only chapters 5 and 6 are
> > the only files affected, so there may not be tha
Dan Nicholson wrote:
To finish this thought, alpha will touch a lot of files once Chris'
dependency info goes in. The build commands are essentially the same
except one change in perl. However, I think only chapters 5 and 6 are
the only files affected, so there may not be that many conflicts.
On 4/4/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> On 4/4/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> > Archaic wrote:
> > > It will be chock full of
> > > conflicts after alpha merges. :)
> >
> > I don't see why there should be many conflicts. Udev_update doesn't
> > touch that many files
On Tue, Apr 04, 2006 at 11:11:44AM -0700, Dan Nicholson wrote:
>
> I just diffed trunk to udev_update the other day when I decided to
> "convert" my system to udev_update for the reasons mentioned in
> blfs-book about HAL. The files are, basically
But udev_update will not be merging to what is c
On 4/4/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Archaic wrote:
> > It will be chock full of
> > conflicts after alpha merges. :)
>
> I don't see why there should be many conflicts. Udev_update doesn't
> touch that many files, IIRC.
I just diffed trunk to udev_update the other day when I d
Archaic wrote:
It will be chock full of
conflicts after alpha merges. :)
I don't see why there should be many conflicts. Udev_update doesn't
touch that many files, IIRC. Regardless, I completely agree that it's
time the two branches got merged. Sadly, I'm unlikely to be able to
take part
Archaic wrote:
On Tue, Apr 04, 2006 at 09:29:48AM -0700, Dan Nicholson wrote:
Say the word, and I'll start firing off the builds later this week.
the word. :)
However, any builds I do would be alphabetical+udev_update.
Yeah, that was my intention. :) I really don't look forward to the
actu
On Tue, Apr 04, 2006 at 09:29:48AM -0700, Dan Nicholson wrote:
>
> Say the word, and I'll start firing off the builds later this week.
the word. :)
> However, any builds I do would be alphabetical+udev_update.
Yeah, that was my intention. :) I really don't look forward to the
actual process o
On 4/4/06, Archaic <[EMAIL PROTECTED]> wrote:
> Short of ICA results, are there any specific reasons why
> udev_update should not be merged into trunk in the next week or two?
Say the word, and I'll start firing off the builds later this week.
However, any builds I do would be alphabetical+udev_
Archaic wrote:
Due to all the ICA testing on the alpha branch, I think it is time to
fold that branch into trunk. Are there any specific reasons why this
should not be done now?
No, not really. It's been ready for a while, save that we were trying to
get all dependency information included as
Due to all the ICA testing on the alpha branch, I think it is time to
fold that branch into trunk. Are there any specific reasons why this
should not be done now?
Following that, I also think it is time to fold udev_update into trunk
and I would welcome some ICA results before that happens. While
58 matches
Mail list logo
