[gobolinux-devel] IRC meeting this weekend - 014.b

[Hisham]

Hi,

I missed the dev meeting (by about 30 minutes I guess), but I read the
logs. (Thanks to Ikkebr for posting them at http://www.hashphp.com/144
-- perhaps they could be copied to somewhere more permanent; are the
others in the wiki?). It was great to see how development is more
focused, with the clear list of bugs, etc.

I didn't go through each entry in the bugtracker but here are some
general comments:

>  2.6.24.x kernel:  This kernel opps while mounting squashfs
>  filesystems.  Obviously, this is a problem for the livecd.  Last I
>  talked with Lucas, he had a few patches to try but I don't know the
>  current status.
>
>  OpenOffice (238):  I've built 2.3.1_bin-r2 in ChrootCompile.  This
>  solved the freedesktop entry problem but openoffice won't load.  I
>  tracked this down to the lack of symlinks in bin (to ../programs) for
>  openoffice.org2.3.bin, soffice.bin, pagein.  Oddly, the recipe makes
>  the soffice.bin symlink.  Also, the soffice link is made twice.
>
>  mplayer (260): need an updated skel (maybe enchanced?) for a
>  ~/.mplayer/subfont.ttf symlink.  Recommendations for the font to use?

In my machine here I have a link
/Programs/MPlayer/Current/Shared/mplayer/subfont.ttf ->
/Files/Fonts/TrueType/Vera.ttf
Perhaps we could even copy the font there, to simplify things.

>  Manpages in share (255):  Already talked to you.  Need a new Scripts
>  package with updated MANPATH (in /S/S/bashrc and zshrc).  This is temp
>  fix until we rebuild packages (015).
>
>  Xorg (282):  Newest revision fixes xcb problems.  I have built and
>  tested this on livecd (using skype).  My package isn't signed.  I need
>  to add my key to Scripts package (above) or have someone else
>  build/sign package.
>
>  Squashfs on AM2 (283):  Unable to reproduce on my AM2 machine.  Is the
>  bug a gross failure or subtle (read corruption)?

I'm not sure, but I think it fails to boot. I have access to an AM2
machine, still need to test this.

>  Boot in VirtualBox (284):  I don't have Virtualbox installed (and no
>  gcc 3.x to build).  If someone has a Virtualbox package I'd appreciate
>  it.  Would rather not introduce gcc3 into my system.
>
>  DBus, no machince-id (247): This is a general problem with Installer
>  not handling PostInstall scripts.  Lucas came up with a quick patch to
>  ProfileInstall that runs PostInstall but it hasn't been tested.  There
>  are other issues wrt PostInstall but I'll cover those below.
>
>  Install not copying /F/Fonts (246): Tracked down to incomplete kernel
>  args (needed maxloop=32) when using AM2 workaround.  Can this be
>  closed?

Yes; I updated http://www.gobolinux.org/?page=known_issues_014
accordingly and closed the bug.

>  Some 014-rc bugs that might need attention.  These should be closed or
>  moved to 014.
>
>  Broken Links after install (199):  RemoveBroken needs to be run in Installer?
>
>  Sudo overwrites files (204): This is a longstanding problems.  There
>  is a suggested change to the sudo recipe in the bug tracker.  Has the
>  recipe been updated?
>
>  InstallPackage error msgs (205):  Notes imply it is fixed.  Should
>  this be closed?

Like I wrote in the bug, I think so. Jonas, what do you say?

>  In a nutshell, we need new Scripts, EnchancedSkel, Installer releases
>  (changes may not be in svn).  Updated Sudo, OpenOffice
>  recipes/packages.  Updated Xorg package.  I'll take ownership of the
>  OpenOffice changes.  They seem to be LiveCD specific.
>
>  Now, to talk about PostInstall.  I'm going to be a bit verbose because
>  I won't be there tomorrow to respond to question regarding what I
>  mean.  The PostInstall script is run to create an EFFECT (I'll use
>  this a lot)  on the system (create id/keys, set ownership based on
>  created user/group, etc).  This effect should be distinct for each
>  install.  The LiveCD is a type of install.  It should be affected by
>  the PostInstall scripts.  Whether this happens during ISO generation
>  or boot is debateable but probably minor.
>
>  So the LiveCD needs PostInstall effects.  These effects should not be
>  mirrored to the HD during install.  During install, PostInstall needs
>  to be run to generate the distinct effects for that system.
>
>  I'm worried that Installer is not sophisticated enough to prevent
>  transferring the LiveCD effects to the HD.  There are only 4
>  PostInstall scripts on the LiveCD, so they can be special cased for
>  014.b but a plan for general use would be great for beyond.  Similar
>  concerns apply for R/Requirements as well.

I believe the effects applied to the LiveCD environment all go into
Settings directories and the user's home directory, while the
Installer does not use these directories, using each package's
Defaults/Settings instead. IIRC, André was the one who worked on this,
so he may be able to confirm. In this case, we shouldn't have a
problem running PostInstalls (for example) on LiveCD boot for the
LiveCD environment, and then running them again for the installed
system.

>  On IRC, Jonas and I discussed upping KDE to 3.5.9.  At that point, I
>  started to think that 014.b could be more than a bugfix release.
>  Keeping the stage 1 core, updating the stage 2 desktop and stage 3
>  apps.  With the timeline, I'm sure that is not feasible. I'd like more
>  details wrt pressing CD.  Is this for a magazine?  Is it worth the
>  rush?  Especially since 014 is a little dated.

Given that KDE 3.5.9 itself is also a bugfix release, I'm kinda
favorable to that idea as well.

>  For the ISO, I'd prefer to receive binary packages.  Hopefully those
>  providing packages would have more detailed knowledge of the
>  application and could test the package thoroughly.  This should catch
>  bugs before they get to an ISO rc.  To implement this, I could set up
>  a webdav dropbox on calica.com.  Maybe ftp as well.  Another option is
>  SVN.  To build packages, you'd just need ChrootCompile on 014.  For
>  015, we could have an image that runs under lguest.  Please discuss
>  this on IRC and provide feedback.

As mentioned in the IRC metting, simpler is better. I'd prefer using ftp.

>  SVN migration.  This requires changes in BuildLiveCD tools.  Hopefully
>  these changes won't take too long to implement or cause other
>  regressions.

Yes. I can look at that later in the week unless someone beats me to it.

-- Hisham