On Thu, 12 May 2011 Kendall Weaver kend...@peppermintos.com wrote:
Thanks for the feedback. It's interesting to see the differences between the
way things are done here at Lubuntu versus other projects I maintain or
contribute to (in addition to Peppermint, I also build the Linux Mint LXDE
and Fluxbox editions). At Peppermint, all testing and developer
collaboration is very locked down ...
While it can have its downside too, I like the be open/public, don't
make a big distinction between those with commit privs and those without
them, make decisions in public view approach. It is also the approach
recommended by Karl Fogel's book Producing Free Software
http://producingoss.com , at least as I understand/intrepret what Karl
says. Worth reading :)
It really is kind of crazy how quickly this was leaked. Do know that this
was not my intention, I just wanted to do something nice for you guys.
Oh, sure! I didn't see the appearance of your ISO as a negative event,
but it may mean that if we do release an official Lubuntu 11.04 amd64
ISO at some stage, finding out whether users have that one, or yours,
when doing support, may be a minor challenge (although see below re.
your volume id!)
I guess it's kind of a habit to go ahead and set labels. Setting this stuff
is usually the first thing I do when putting together an .iso file. I've
seen far too many official images that have been mislabeled in my life so
I usually just go ahead and set this up without thinking much about it.
If the script does the labelling, it is much harder to get wrong than
if a human has to remember to change it each time by hand, see below :)
I'm not sure how the real Ubuntu image creation setup handles this; I suspect
I'll get to know it fairly deeply in a few weeks time!
I want to be able to use that infrastructure to create and publish
daily or weekly ISO images as we progress through Alpha and Beta for
11.10. It is already set up for doing that. In contrast, that high a
frequency of image updating is probably beyond the patience of most
humans, even if they are as comfortable and experienced with
hand-creating ISOs as you seem to be :)
On that note, signing .iso files is a rather
fantastic idea and I'll consider this in Peppermint and will bring it up to
Clem at Linux Mint and see what he says.
Go for it... our script does something like
IMAGE_NAME=Lubuntu ${release} $(date -u +%Y%m%d) - ${arch}
ISOFILE=lubuntu-${release}-$(date -u +%Y%m%d)-${arch}.iso
sudo mkisofs -r -V $IMAGE_NAME -cache-inodes -J -l \
-b isolinux/isolinux.bin -c isolinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
--publisher Lubuntu Packaging Team \
--volset Ubuntu Linux http://www.ubuntu.com; \
-p ${DEBFULLNAME:-$USER} ${DEBEMAIL:-on host $(hostname --fqdn)} \
-A $IMAGE_NAME \
-m filesystem.squashfs \
-o ../$ISOFILE .
at the moment. ISO images have many fields in them for info on
the publisher, application, etc., in the ISO filesystem header -- so we
might as well fill some of them in! Your image seems to be leaving all
of Volume set id, Data preparer id, and Publisher id empty, and using
the default (an ad for genisoimage!) in the application id.
If you don't want to remember all the option switches, you can create a
~/.genisoimagerc file with a set of strings that will become your new
defaults -- that might suit your style of ISO creation better than the
lengthy command above :)
If I were in your shoes I would go ahead and take a bit of time to address
the current build script. Causality is very important in my opinion and
regardless of the potential future obsolescence of the script, moving
forward with that knowledge strikes me as more sound than moving forward
without it.
Agreed in principle; my time for all this is not infinite though :)
As long as each component is correct and in the
correct location, then I don't see why it matters how each one got there.
Repeatability, ease of automated daily builds, etc. are the main
pluses I can see that are difficult for humans to match. At least in
theory, with a script you only make a mistake once; thereafter you fix
the script, and that particular mistake will not happen again :)
..., it's been rather obvious that the demand for a well put together
Ubuntu based 64 bit LXDE distro has been there for a while.
Agreed, although I'm a little puzzled by it; generally speaking 64bit
addressing doesn't get you anything useful until you have 4GB or more
of RAM, and most 64bit PC CPUs are multicore; run on that level of PC
hardware, the extra overhead of GNOME or Xfce is really not all that
noticeable/bad, IMO. I'm not discouraging 64bit Lubuntu at all, once we
have an official one, I'm likely to run it on my own main development
PC, ... *but* I'm not really sure why there is so much interest in a
64bit LXDE-based distro. Are there really a lot of slow, old, low-RAM
64bit PCs out there that people feel a need to run a
