Announcements

[netnomad]

hi jason,

booting with md5-files has the same effects, but the boot-process takes additional 30s.

thank you for all your commitment to this project

[Jason W]

Hi netnomad,

It is the package libkpathsea6.  I re-imported that same 100-desktop-jessie package showing the .15 MB to download though updatesce said no updates, and when importing it yet again and then rebooting it showed 00.00 size to download on a subsequent import.

Lets keep our eye out for any other time that updatesce says no updates yet there is a new deb downloaded upon importing. 

Oh, and I will consider an expert option of not creating md5sum files for the imported SCEs.  Would be simple and not disrupt things, can be put in /etc/sysconfig/sceconfig for persistence.

Evidently there is an issue with the updatesce checking of the 000-base-jessie type of SCEs.  Will check into it.  Most likely the issue with the above mentioned deb that was to be updated.

[Jason W]

I found the fix, a very simple but large bug in importupdatecheck.  I will test over the next day or so and upload the results.

[Jason W]

Uploaded the fix for the x86 dCore ports.  Please test.

[Jason W]

netnomad -

I saw that on a 1.9 GB SCE extension on my usb key, it takes 1 min 36 sec to simply md5sum check it.  Since there can be a performance hit that not everyone wants when using loadsce, I added a boot code "nomd5" that will let loadsce load SCEs without md5sum checking them which can save a bit of time if they are large.  This is an expert option, and assuming there is any trouble when using this that the first thing to do is run an md5sum check on the SCE directory.  I used a boot code since this way importsce will create the proper md5sum file that can later be used to check the integrity of the extension later, and since an option in /etc/sysconfig/sceconfig has to be backed up and restoring the backup occurs after extensions are loaded at boot.

Updated the x86 dCore ports, please test.

[netnomad]

hi jason,

the first impressions and heavy testing proved the working updatesce-process

good cut, thank you for your work and commitment

[Jason W]

Some new changes have been uploaded:

SCEs are moved from update during shutdown, for a faster boot.

SCEs are updated in a reverse tree method for better dependency integrity.  Also SCEs in the update directory are used if there during import and update when determining package contents and md5 data.

[Jason W]

Uploaded a bug fix, changing contents of sce.dep files wheither manually or by re-importing using the -d option will now cause SCEs that depend on the one with the changed .dep file to report needing an update when updatesce is run.

Simply importing the SCEs that depend on the changed one already accounts for any missing or changed entries in dep files.

[netnomad]

hi jason,

last cut with "update -c -a" reports for my config:

> Do you want to review the list of packages that have updates available?
> Enter y to view and q to exit reading the package list. (y/N): y

but then no updates are available in the package list!

this is no serious bug, but probably you want to be informed?

thank you for your work.

[netnomad]

hi jason,

the last cut starts with "updatesce -a" something like an update-loop

i guess that for all packages the dependencies are updated again and again.

thank you for your work and patience.

[Jason W]

I am having to use a loop to make a reverse tree update process for each sce and it's deps.  The dependencies should not be updated again and again, if so that is a bug.  I will test further.

[Jason W]

Things should be working now, please test, new cut uploaded.

[netnomad]

hi jason,

i assume that this behavior is correct? :

100-desktop-jessie, 200-multimedia-jessie, libreoffice and vbox are based on 000-base-jessie,
so after an update of 000-base-jessie all other packages need to be re-imported?
this happened for me... just one little package in 000-base-jessie needed an update,
so all other packages that are based on this base-packages were re-imported.

after the re-import and the reboot,
"update -a -c" results in following message:

tc@box:~$ updatesce -c -a
debian
#################### 100.0% 0.0 kBps DONE   
verifying download...checksum matches OK
used 10688512 local, fetched 0
Using the repo http://ftp.us.debian.org/debian debian jessie main
Searching for availbe updates for chosen SCEs.
000-base-jessie
100-desktop-jessie
200-multimedia-jessie
libreoffice
original-modules-3.8.13-tinycore
vbox
Do you want to review the list of packages that have updates available?
Enter y to view and q to exit reading the package list. (y/N):

and the list is empty:

SCE:  000-base-jessie
  Available package updates:
None
SCE:  100-desktop-jessie
  Available package updates:
None
SCE:  200-multimedia-jessie
  Available package updates:
None
SCE:  libreoffice
  Available package updates:
None
SCE:  original-modules-3.8.13-tinycore
  Available package updates:
None
SCE:  vbox
  Available package updates:
None

thank you for your help and work.

[Jason W]

Basically that is the desired behavior.  It sounds like overkill, but lets say you specify libtiff-tools as a package in the list of 000-base-jessie, and it depends on liblzma5.  If dependencies change of libtiff-tools and it no longer depends on liblzma5, then if 100-desktop-jessie has a package that depends on liblzma5 and it was originally satisfied by that SCE depending on 000-base-jessie, after the update 100-desktop-jessie is now broken.  Dependencies don't often change but the sometimes do especially when a Debian release is still in the "testing" stage. 

[netnomad]

Basically that is the desired behavior.

i understand, but nevertheless the "updatesce -a -c" reports a required update and then the list for updates is empty :-(
basically the intended behavior seems to be fullfilled.

thank you for your help.