lubuntu-desktop team mailing list archive

[Jonathan Marsden <jmarsden@xxxxxxxxxxx>]

On Thu, 12 May 2011 Kendall Weaver <kendall@xxxxxxxxxxxxxxxx> 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 64bit OS on?  Or
are there some nifty 64bit-only Linux apps that I don't know about? :)

> ... could more easily offer a better system in both architectures for 
> Peppermint Two (which should be out in a couple of weeks).

Grin!  Please try:

  file Lubuntu-11.04-amd64.iso

or

  isoinfo -d -i Lubuntu-11.04-amd64.iso |head

You left a remnant of "Peppermint Two" in your Lubuntu amd64 ISO :)  

I saw that and smiled... another reason not to do ISO image creation by
hand?  That ISO file is definitely not what its Volume Id says it is,
and since volume ID is displayed in some file mangers for identifying
ISOs, I think it's good to have that string be meaningful and accurate.

> Regardless, I figured it might be a good experiment to more accurately
> judge demand for such a system.

The demand is clearly there :)

> Anyway, if it's at all possible, I'd really like to look into having a good
> collaborative relationship with Lubuntu and all that you guys do. People are
> constantly grating on Linux distributions for not adequately contributing
> upstream and I don't want that to be the case. If I come across something
> that can benefit all of us I do want to make sure that you guys are aware.

Works for me :)  We have a significant todo list item of "get all the
relevant LXDE fixes in Lubuntu into the upstread LXDE codebase" on our
plate at the moment...  I think/hope that will be mostly Julien's task,
but that's one specific way we are trying to avoid the "doesn't
contribute upstream" label ourselves.  If you have fixes/patches in
Peppermint LXDE (or other) packages that would be useful upstream, I
would encourage you to consider doing the same with your work.
Equally, if you have made packaging fixes, getting them into Debian
would be great, then we all benefit.

Jonathan