On Thu, 12 May 2011 Kendall Weaver <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~lubuntu-desktop Post to : [email protected] Unsubscribe : https://launchpad.net/~lubuntu-desktop More help : https://help.launchpad.net/ListHelp
