5:31 a.m.
This patch introduces a global variable 'interactive' which is defined
as true if stdout of livecd-creator is attached to a tty. This global
is then used to add the -no-progress option to mksquashfs for
non-interactive sessions. Thus making logfiles created by redirecting
the output of livecd-creator, reasonably readable (e.g. with less).
This may or may not solve the root issue that Jon Steer recently brought
up. (maybe he wants it disabled even in terminal situation, in which
case a --verbose/--debug/--quiet infrastructure is called for, which IMO
would be a great addition as well).
This specific case, might also be better as an upstream mksquashfs
modification (Phillip, should I submit a patch?), but I think the global
is handy, for instance if we want to provide our own progress bar.
Comments welcome on generic style issues as always (is there something
preferable to a global in this instance?)
-dmc
7:31 p.m.
On Sun, 2007-09-23 at 05:31 -0500, Douglas McClendon wrote:
This patch introduces a global variable 'interactive' which
is defined
as true if stdout of livecd-creator is attached to a tty. This global
is then used to add the -no-progress option to mksquashfs for
non-interactive sessions. Thus making logfiles created by redirecting
the output of livecd-creator, reasonably readable (e.g. with less).
I'm not sure how useful it really is as a global when we're using it for
one thing. If we find more places that we want it, I might be convinced
to make it more generally accessible, but until then, it just feels a
little bit like polluting the namespace.
Also, the more pythonic way to check is looking at sys.stdout.isatty()
rather than os.isatty(Fdno) -- makes it a little bit more obvious to
those who don't instinctively know "well duh, fd 1 is stdout"
Jeremy
8:49 p.m.
On Sun, 2007-09-23 at 20:31 -0400, Jeremy Katz wrote:
On Sun, 2007-09-23 at 05:31 -0500, Douglas McClendon wrote:
> This patch introduces a global variable 'interactive' which is defined
> as true if stdout of livecd-creator is attached to a tty. This global
> is then used to add the -no-progress option to mksquashfs for
> non-interactive sessions. Thus making logfiles created by redirecting
> the output of livecd-creator, reasonably readable (e.g. with less).
I'm not sure how useful it really is as a global when we're using it for
one thing. If we find more places that we want it, I might be convinced
to make it more generally accessible, but until then, it just feels a
little bit like polluting the namespace.
Also, the more pythonic way to check is looking at sys.stdout.isatty()
rather than os.isatty(Fdno) -- makes it a little bit more obvious to
those who don't instinctively know "well duh, fd 1 is stdout"
And done in my local tree[1] while moving mksquashfs into its own
function. This adds the advantage of we don't need to copy around the
hack of setting PWD in the environment as we have more than one place
that we execute mksquashfs now.
Jeremy
[1] Not pushed to master as I'm about to head off to watch some TV
before going to bed and thus want to make sure that the image I have
going _finishes_ before pushing it
9:23 p.m.
New subject: non-vfat msdos usb sticks, persistence, misc... was Re: [PATCH] disable mksquashfs progress bar for non-interactive sessions
Jeremy Katz wrote:
On Sun, 2007-09-23 at 20:31 -0400, Jeremy Katz wrote:
> On Sun, 2007-09-23 at 05:31 -0500, Douglas McClendon wrote:
>> This patch introduces a global variable 'interactive' which is defined
>> as true if stdout of livecd-creator is attached to a tty. This global
>> is then used to add the -no-progress option to mksquashfs for
>> non-interactive sessions. Thus making logfiles created by redirecting
>> the output of livecd-creator, reasonably readable (e.g. with less).
> I'm not sure how useful it really is as a global when we're using it for
> one thing. If we find more places that we want it, I might be convinced
> to make it more generally accessible, but until then, it just feels a
> little bit like polluting the namespace.
>
> Also, the more pythonic way to check is looking at sys.stdout.isatty()
> rather than os.isatty(Fdno) -- makes it a little bit more obvious to
> those who don't instinctively know "well duh, fd 1 is stdout"
yeah, that sounds better. As did the loop.max_loop choice.
And done in my local tree[1] while moving mksquashfs into its own
function. This adds the advantage of we don't need to copy around the
hack of setting PWD in the environment as we have more than one place
that we execute mksquashfs now.
Note, I forgot to do an os.unlink of osmin from build_dir/data after its
mksquashfs. So until you do that, an extra 10kb or so is wasted with an
extra copy in the main squashfs.
I won't try to offer a patch as I'm sure you can do it easily, and with
the layout flux... I'd suggest... hmm... msdos(not vfat) sticks?...
Is it really worth supporting msdos-nonvfat filesystems? Is any stick
that isn't meant to be capable of holding an mp3 with a beyond 8.3
filename really worth supporting? Do sticks/cards often come
preformatted that way? ( maybe they do... :( )
Clearly that would shoot down the last of my layout changes that adds
the fslabel to the squashfs.img filename (unless you fell back to
checking for the shorter version).
I had been thinking given that naming scheme, that this new file should
fit in similarly as fslabel.squashfs.mininst.img (or something).
Finally, just a heads up, the remaining patches you might see soon, are
the zenity-isotodisk, and a resend of the overlay/persistence. I think
the latter might be worth considering applying before the devel freeze
because
a) it's such a useful feature,
b) it could/would/should be turned off by default(for F8),
c) it does actually work as long as you shutdown cleanly, and
d) we do have plenty of time to fix bugs with it and make it more
robust, or as a contingency, easily extricate it before F8.
-dmc
10:53 p.m.
New subject: non-vfat msdos usb sticks (was related to squashed osmin naming)
Douglas McClendon wrote:
Is it really worth supporting msdos-nonvfat filesystems? Is any
stick
that isn't meant to be capable of holding an mp3 with a beyond 8.3
filename really worth supporting? Do sticks/cards often come
preformatted that way? ( maybe they do... :( )
I just tested what I thought was the case- you can have disk fdisk-ed as
non-vfat msdos (6 - fat16), then mkfs.msdos it, then mount it as vfat,
and all is well. Is there a case when that can't be relied on? I.e.
perhaps when it isn't linux doing the mkfs.msdos?
The case you mentioned was for osmin.squashfs.img->osmin.img. Assuming
vfat can be relied upon(??), I can see that maybe having value before we
move it under /LiveOS. But once under /LiveOS it seems reasonable to
stick with the nice long intuitive/descriptive filenames. And thus in
the rare case that that subdir is perused when mounted non-vfat, it's
just OK that it clearly has stuff with long filenames that has been
converted to the ugly dos 8.3 version.
-dmc
1:02 p.m.
New subject: non-vfat msdos usb sticks, persistence, misc... was Re: [PATCH] disable mksquashfs progress bar for non-interactive sessions
On Sun, 2007-09-23 at 21:23 -0500, Douglas McClendon wrote:
Note, I forgot to do an os.unlink of osmin from build_dir/data after
its
mksquashfs. So until you do that, an extra 10kb or so is wasted with an
extra copy in the main squashfs.
Done.
I won't try to offer a patch as I'm sure you can do it
easily, and with
the layout flux... I'd suggest... hmm... msdos(not vfat) sticks?...
Is it really worth supporting msdos-nonvfat filesystems? Is any stick
that isn't meant to be capable of holding an mp3 with a beyond 8.3
filename really worth supporting? Do sticks/cards often come
preformatted that way? ( maybe they do... :( )
Trying to guarantee anything about how things come pre-formatted seems
to be ... a path to losing, sadly. And really, when there's not a good
reason _to_ use long file names, we might as well be conservative.
Clearly that would shoot down the last of my layout changes that adds
the fslabel to the squashfs.img filename (unless you fell back to
checking for the shorter version).
I'm not sold on label in the filename, to be honest. Especially with
then having to encode it on the filesystem to work with USB sticks given
the UUID fun. Which is why I backed off on it a little before Fedora 7
when the idea came up.
Jeremy
3:51 p.m.
New subject: non-vfat msdos usb sticks, persistence, misc... was Re: [PATCH] disable mksquashfs progress bar for non-interactive sessions
Jeremy Katz wrote:
On Sun, 2007-09-23 at 21:23 -0500, Douglas McClendon wrote:
> Note, I forgot to do an os.unlink of osmin from build_dir/data after its
> mksquashfs. So until you do that, an extra 10kb or so is wasted with an
> extra copy in the main squashfs.
Done.
> I won't try to offer a patch as I'm sure you can do it easily, and with
> the layout flux... I'd suggest... hmm... msdos(not vfat) sticks?...
>
> Is it really worth supporting msdos-nonvfat filesystems? Is any stick
> that isn't meant to be capable of holding an mp3 with a beyond 8.3
> filename really worth supporting? Do sticks/cards often come
> preformatted that way? ( maybe they do... :( )
Trying to guarantee anything about how things come pre-formatted seems
to be ... a path to losing, sadly. And really, when there's not a good
reason _to_ use long file names, we might as well be conservative.
> Clearly that would shoot down the last of my layout changes that adds
> the fslabel to the squashfs.img filename (unless you fell back to
> checking for the shorter version).
I'm not sold on label in the filename, to be honest. Especially with
then having to encode it on the filesystem to work with USB sticks given
the UUID fun. Which is why I backed off on it a little before Fedora 7
when the idea came up.
Yeah, complexity-wise it was more than all the other stuff combined, for
a smaller immediate benefit.
-dmc
6059
days inactive
6060
days old
livecd@lists.fedoraproject.org
6 comments
2 participants
participants (2)
-
Douglas McClendon -
Jeremy Katz