[opensuse-factory] openSUSE Leap 42.2 GM done
Hi, openSUSE Leap 42.2 is build disabled now. The final images have been built. To get them please hold out until the official release on Wednesday to let the mirrors warm up. Important fixes need to be submitted via the update project now. If anything needs to be fixed urgently to be available at the release day, please - talk to maintenance (Bugzilla NEEDINFO maintenance@opensuse.org) - thoroughly test your changes! Thanks everyone for your contributions and hard work to make 42.2 a great release! cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On jeudi, 10 novembre 2016 17.32:35 h CET Ludwig Nussel wrote:
Hi,
openSUSE Leap 42.2 is build disabled now. The final images have been built. To get them please hold out until the official release on Wednesday to let the mirrors warm up.
Important fixes need to be submitted via the update project now. If anything needs to be fixed urgently to be available at the release day, please - talk to maintenance (Bugzilla NEEDINFO maintenance@opensuse.org) - thoroughly test your changes!
Thanks everyone for your contributions and hard work to make 42.2 a great release!
cu Ludwig
Thanks for your leadership too :-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/11/2016 18:32, Ludwig Nussel wrote:
Hi,
openSUSE Leap 42.2 is build disabled now. The final images have been built. To get them please hold out until the official release on Wednesday to let the mirrors warm up.
Important fixes need to be submitted via the update project now. If anything needs to be fixed urgently to be available at the release day, please - talk to maintenance (Bugzilla NEEDINFO maintenance@opensuse.org) - thoroughly test your changes!
Thanks everyone for your contributions and hard work to make 42.2 a great release!
cu Ludwig
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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. 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? 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? Thank you. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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, Nov 12, 2016 at 12:19 PM, Dominique Leuenberger / DimStar
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 time /usr/bin/update-mime-database /usr/share/mime Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' real 0m23.765s user 0m0.613s sys 0m0.366s ----- # export PKGSYSTEM_ENABLE_FSYNC=0 linux:/var/log/zypp # time /usr/bin/update-mime-database /usr/share/mime Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' real 0m0.473s user 0m0.404s sys 0m0.068s ------ 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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, Nov 12, 2016 at 1:15 PM, Dominique Leuenberger / DimStar
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? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 2016-11-12 12:19, Dominique Leuenberger / DimStar wrote:
On Sat, 2016-11-12 at 11:29 +0100, cagsm 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).
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. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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 2016-11-12 23:35, Dominique Leuenberger / DimStar wrote:
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 :)
Yes, you are right :-) I can see that by default, the operation is not cached, and quite disk intensive. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 42.2, at Minas-Anor) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Nov 12, 2016 at 11:29 AM, cagsm
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
participants (6)
-
Bruno Friedmann
-
cagsm
-
Carlos E. R.
-
Dave Plater
-
Dominique Leuenberger / DimStar
-
Ludwig Nussel