On Fri, 2016-11-11 at 08:45 +0200, Dave Plater wrote:

I see that my local mirror has  openSUSE-Leap-42.2-DVD-x86_64-Build0272-Media.iso, is this the final  release? Thanks Dave P

No, Build 272 was RC2; As Ludwig said, and as it was in the past: GM is being synced in the background but is not published yet. Mirrors slowly build up receiving the file - but will only show it on release date. Cheers, Dominique

On Sat, 2016-11-12 at 11:29 +0100, cagsm wrote:

Changed my 42.1 default repos all to the 42.2 path and zypper ref'd and zypper dup'd

Watching zypper progress, I have seen countless update-mime-dat(atbase) in top and in the zypper output, at a lot of times creating really long stalls

That sounds like a very old bug is back in the game - OR a lot of packages not respecting the macro they should be using. Let's first see which of the two statements is true: Call the commands in sequence (as root, in one session please, not using sudo)$ time /usr/bin/update-mime-database /usr/share/mime $ time /usr/bin/update-mime-database /usr/share/mime $ export PKGSYSTEM_ENABLE_FSYNC=0 $ time /usr/bin/update-mime-database /usr/share/mime Is there a notable difference in the execution time between the first and the 2nd call (I'd expect yes... on my test system this changes from ~40s to ~2s). If on your system this also does change as expected, we might have some packages that do not use the %mime_database_post macro but decided to call /usr/share/update-mime-database directly. That would be packaging bugs then though.

Can we not only once or few times call this update-mime-database program? Didnt we reduce the multiple calls from previous opensuse versions for those boot and grub and kernel and lvm2 and related things that had been called a zillion times as well, and meanwhile reduced to a single call or very few calls only?

for the mime-database, that was so far not moved to posttrans; but that should certainly be doable and sounds like a realistic goal.

Does update-mime-database work when it would be called at the very end? Can I call it manually from command line and it will take into account all the stuff that packages have brought in as new information? What does update-mime-database operate on exactly?

update-mime-database should not stop the installation of other packages and their post scripts if only started at the end of the transaction. Moving it should be possible. As for starting manually: that's what the commands earlier in this mail do, so yes, you can. Cheers, Dominique

On Sat, 2016-11-12 at 12:50 +0100, cagsm wrote:

On Sat, Nov 12, 2016 at 12:19 PM, Dominique Leuenberger / DimStar wrote:

...

Call the commands in sequence (as root, in one session please, not using sudo)$ time /usr/bin/update-mime-database /usr/share/mime

$ time /usr/bin/update-mime-database /usr/share/mime $ export PKGSYSTEM_ENABLE_FSYNC=0 $ time /usr/bin/update-mime-database /usr/share/mime

Is there a notable difference in the execution time between the first and the 2nd call (I'd expect yes... on my test system this changes from ~40s to ~2s).

there is a huge difference

The difference is expected - and shows that the infrastructure is correct; hence, some packages call it wrong.

During zypper dup I have seen a lot of those weird messages with tat all/all and all/allfiles unknown type complaints. Thats how I noticed that it was called many times over. But then again I have seen these mime messages for many years with opensuse distribution.

the all/all and all/allfiles are 'cosmetic noise' - the actual goal has to be to find what calls update-mime-database without the macro. This warrants a bug report in my opinion Cheers, Dominique

On Sat, 2016-11-12 at 13:19 +0100, cagsm wrote:

On Sat, Nov 12, 2016 at 1:15 PM, Dominique Leuenberger / DimStar wrote:

...

The difference is expected - and shows that the infrastructure is correct; hence, some packages call it wrong.

How can I list or find out which packages call that update-mime-database exactly and in what ways? Or should some zypper post update/upgrade global script only call it exactly once at the end of the whole process?

The posttrans implementation would take even longer to fix (and would need more testing). I'd say in a first step, packages should be fixed to use the right macro. Sadly, at the moment, I only have a Tumbleweed checkout available to run the test against - I'll try to get to the Leap one in the next few days. For TW, the command used, and the result received, looks like: find -maxdepth 2 -name '*.spec' -exec grep -l update-mime-database {}\; ./akonadi-runtime/akonadi-runtime.spec ./blender/blender.spec ./bluefish/bluefish.spec ./boo/boo.spec ./conglomerate/conglomerate.spec ./fyre/fyre.spec ./gcstar/gcstar.spec ./gDesklets/gDesklets.spec ./geda-gaf/geda-gaf.spec ./genius/genius.spec ./glom/glom.spec ./gns3/gns3.spec ./icc-examin/icc-examin.spec ./jamin/jamin.spec ./kdepimlibs4/kdepimlibs4.spec ./klatexformula/klatexformula.spec ./libfm/libfm.spec ./OpenLP/OpenLP.spec ./opt_gnome-compat/opt_gnome-compat.spec ./pcb/pcb.spec ./pitivi/pitivi.spec ./planner/planner.spec ./python3-veusz/python3-veusz.spec ./rosegarden/rosegarden.spec ./scribus/scribus.spec ./shared-mime-info/shared-mime-info.spec ./vym/vym.spec ./yast2-metapackage-handler/yast2-metapackage-handler.spec Some of them might be false positives (like pitivi for example, which has a %post script still supporting legacy systems which did not have the macro; but it uses the direct command only in this case, the macro on modern dists) Anyway: those are certainly a good starting point, as if they are wrong in TW< they are very surely also wrong in Leap. You might also use your own logs to find which packages stalled for a long time - and report against those if they are not listed above Cheers, Dominique

On Sat, 2016-11-12 at 14:39 +0100, Carlos E. R. wrote:

Careful. I don't know if this is the case, but with programs that work with databases (rpm database, for instance) there is often a huge difference between the first and subsequent runs because the first run caches the disk files into ram.

In that case, you should run a third time removing the variables exported in the second command.

I know this update-mime-database pretty well to understand what kind of difference comes from a hot cache or not.. the numbers presented are clearly not related to hot vs cold cache execution... bu tfeel free, give it a try and run it as often as you want without the variable set :) Cheers, Dominique

On Sat, Nov 12, 2016 at 11:29 AM, cagsm wrote:

program? Didnt we reduce the multiple calls from previous opensuse versions for those boot and grub and kernel and lvm2 and related things that had been called a zillion times as well, and meanwhile reduced to a single call or very few calls only?

Btw: I just looked at some other machine, 42.1 to 42.2 zypper dup as well. The dracut messages appear rather towards the beginning when the old 4.1 kernel gets uninstalled and then the 4.4.soemthing kernel installed and then again the whole lot of dracut and bootloader messages at posttrans script at the very end. Or are these end messages only a summary or a copy of the ones that actually took place around the kernel package install? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org