[pkg-fso-maint] [PATCH] install.sh: add $SD_PART1_SIZE and $SD_SWAP_SIZE user variables

[Steffen Moeller]

Hi Luca,

Luca Capello wrote:

> On Thu, 19 Feb 2009 13:34:21 +0100, Steffen Moeller wrote:
[...]

>> Luca Capello wrote:
>>> I, at least, will support only one Debian kernel version, the latest
>>> packaged.
> [...]
>> The option for a larger boot partition from my understanding is not
>> adding to anything that you should support. It only increases freedom
>> for users.
> 
> Point taken, even if my remark was not specific to /boot on vfat, but on
> the fact that you were comparing 2.6.24 (an old kernel) with 2.6.28 (the
> latest one, thus the one I support).

We should eventually come up with instructions for our users to report issues that they
guess might be related to the kernel. And right, only the latest version should be supported.

>>> On Wed, 18 Feb 2009 22:39:47 +0100, Steffen Moeller wrote:
>>>> Luca Capello wrote:
>>>>> Please, use uppercase variables.
>>>> They are intentionally lowercase since they are of internal use only.
>>> I was expecting this answer: in this case, I would prefix them with
>>> something like INT_NAME.
>> Fine. If you could accept (what you want to accept) the way it is,
>> then I will go over it and change variable names to receive an
>> "intern_" prefix.
> 
> I think there is a misunderstanding here: it is not me that must/should
> accept, since I was not delegated to be install.sh maintainer (FYI
> Joachim started coding it) nor I want this power.  I have commented on
> your patches with my opinions, since I, again, consider any effort on
> install.sh a loss of time, full stop.  But it seems that I am the only
> one who thinks like that, thus I will stop complaining.

I had checked out d-i today and had a first look. Expect first serious comments over the
next week.

Joachim, I think I want to accept your offer to have commit rights. From what I understood
today I will prior to an upload (to a branch of your liking)

 * undo the vfat kernel text
 * undo the fbpanel addition
 * keep swap
 * keep SD_PART1_SIZE
 * prefix names of internal variables

which should then become the next stable version. To that, upcoming versions should

 * add the matchbox-desktop to ~/.xsession (Joachim)
 * have wicd as an option for wifi with an non-disturbed usb0 connection  (Gregor)

>>> BTW, there is no way to modify a patch once it has been applied
>>> without providing a new commit.  In your case, what you should have
>>> done is
> [...]
>> Many thanks!
>>
>> Should I better follow Joachim's suggestion to find a publicly
>> accessible location of my git repository?
> 
> Having a public repository is always a good thing, but I still prefer
> patches directly sent to mailing lists, because:
> 
> 1) it is easier to comment on
> 
> 2) if you read the mailing lists offline, you have the patches as well
> 
> 3) they are archived somewhere (mailing list archives)
> 
> If you need space, Alioth (the GForge clone provided by Debian at
> http://alioth.debian.org/ ) offers the possibility to host personal
> repositories for various VCSs, including Git:
> 
>   http://wiki.debian.org/Alioth/Git
> 
> Another option will be the one Joachim already offered you, i.e. you get
> commit access to the pkg-fso repository:
> 
>   http://git.debian.org/?p=pkg-fso/files.git;a=summary
> 
>> Every change would then become a branch, and you diff against or
>> between these branches, right?
> 
> More or less, yet.
> 
>> For now, I wish you could accept of what seems remotely acceptable for
>> you, and you specify a list of changes that I should come up with for
>> me to chase up.
> 
> As I stated before, I will stop complaining about new features in
> install.sh and simply review the patches from a "code POV" :-)

I know this to be very difficult. So, I can only say "thanks".

>> Maybe a second file, install-dev.sh, would be a good target? Or the
>> current one becomes install-stable.sh?
> 
> This is a no-op for me, sorry, since we are adding another level of
> complexity.

Right. But I like what JOSM (openstreetmap editor) is doing. They have josm-latest and
something like "latest stable". But still, you are right, since we all have the same
devices and install.sh only does the minimal setup, it shoul be possible to test by
oneself what one is uploading.

>>>> If something went wrong, then cat `ls -lt /tmp/argsToFdisk*|head -1`
>>>> will print the commands sent to fdisk.
>> There seems to be a bug with busybox since "head -1" does not seem to
>> work there.
> 
> `man head`: the correct invocation is `head -n 1` ;-)

Ah. Right. Either works under the regular Debian shell

root at om-gta02:~# head -1 /etc/hosts
head: invalid option -- 1
BusyBox v1.11.1 (2008-12-17 11:16:00 CST) multi-call binary

Usage: head [OPTION]... [FILE]...

root at om-gta02:~# chroot /mnt/debian head -1 /etc/hosts
127.0.0.1 localhost

[....]


Many greetings

Steffen