Involved Projects and Packages
These are all the comments this user made
In 15.2 you can use prime render offloading instead, works just as well...
VB on Leap 15.1 will NEVER be changed to match Factory. When I took the maintainer position, I was told that it was my option to keep an old VB series for old releases, even though I changed the series for the current release. That is the policy that I chose, and continue to use. Accordingly, Leap 15.2 will use VB from the 6.0.x releases, but 15.1 will stay with 6.0.x.
If this policy is no longer acceptable, I am more than willing to turn the VB maintainership over to someone new.
Fixed. We use a tar_scm service to exclude non-OSS code. And each time need to remove git clone folder manually, otherwise the source won't be updated.
I'll submit current pdns-recursor later to SLE-12-SP3 later as SP1 has too old boost version.
Looks good to me, but is there any chance to get it building on at least Leap 15.2?
I will have a look at the GLES patch and send it to your home repo.
Probably need to build using the bundled PEGTL for openSUSE < 1550. I'll take a look at it more closely tonight. Thanks for the review.
Fails to build without pegtl .>= 2.0; I think the correct thing to do is to get pegtl updated in Leap:15.2 (see sr#804129) rather than trying to build vtk without it (or with a bundled version of it).
We got the latest pegtl included in Leap:15.2, but vtk builds fail for 15.2 anyway. I don't have the time to look at why over the next couple of days at least.
Build fails with:
[ 176s] ../../bin/vtkWrapHierarchy: error while loading shared libraries: libvtkWrappingTools.so.1: cannot open shared object file: No such file or directory
Why I have no idea yet ...
Please report issues at https://bugzilla.opensuse.org - These comments are not read by the people that would need to act on them.
the kubectl package is not in openSUSE:Factory and should not be built for any openSUSE distribution
"%if 0%{?is_opensuse} && ! 0%{?is_backports} ExclusiveArch: do-not-build %endif"
I should say this is all backwards compatible and the only new macro is cmake_builder_deps, which is optional.
Calling cmake instead of builders has allegedly performance impact that is noticeable.
Well yes, and this overhead is causing noticeable performance issues.
Hmm,
I did the following test to measure the launch overhead: ``` cd votca-tools/build ln -s /usr/bin/ninja ninja cmake -GNinja -DCMAKE_MAKE_PROGRAM=$PWD/ninja .. ln -sf /bin/true ninja time cmake --build .
real 0m0.005s user 0m0.001s sys 0m0.005s ``` (compare here: https://build.opensuse.org/package/show/home:cjunghans:branches:devel:tools:building/votca-tools)
which is basically nothing. After the launch through CMake there should be no difference.
the "or" in the License tag should be uppercase, see https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
Still now answer on my comment about the line break in the work line
Currently, anyone doing a default install will end up with broken Hangul glyphs (i.e. just boxes), see the e.g. https://openqa.opensuse.org/tests/1102602#step/ibus_test_kr/18
Can we get this in, please? Or do something else to get this resolved ...
So, what happens if you remove "Recommends: noto-sans-kr-fonts" but keep only "Requires: scalable-font-ko"?
With recommends:
The following 5 NEW packages are going to be installed:
ibus-hangul libhangul1 noto-sans-kr-bold-fonts noto-sans-kr-fonts noto-sans-kr-regular-fonts
The following recommended package was automatically selected:
noto-sans-kr-fonts
Without recommends:
The following 3 NEW packages are going to be installed:
alee-fonts ibus-hangul libhangul1
I.e. zypper chooses the (alphabetically) first package which fits, i.e. it installs a semi-random font package.
And doesn't alee-fonts show any proper Koren glyph? If so, it implies that the Provides in alee-fonts is wrong, and we should get rid of it, no?
Depends on the definition of "proper" - the included fonts (5 different families) are apparently complete and likely correct.
But this does not mean alee-fonts is a good default choice - Noto Sans is IMHO much better designed, with proper hinting and the like.
The 5 fonts from alee-fonts: - https://fontinfo.opensuse.org/fonts/BandalRegular.html - https://fontinfo.opensuse.org/fonts/BangwoolRegular.html - https://fontinfo.opensuse.org/fonts/EunjinRegular.html - https://fontinfo.opensuse.org/fonts/EunjinNakseoRegular.html - https://fontinfo.opensuse.org/fonts/GuseulRegular.html
Noto Sans: https://fontinfo.opensuse.org/fonts/NotoSansKRRegular.html
What what are the reasons to not make Noto Sans the default? The user can choose any other font any time, it is only a weak dependency.
If you think there is a better default, I am open for suggestions. But we should choose one to get deterministic results. We should choose a font which renders nicely to avoid any 'asian fonts on SUSE look like shit' reports.
We should choose a font which renders nicely
Unfortunately, what is difficult is that we don't have perfect Asian fonts so far. I am not sure which one is better.
So, what are you missing in Noto Sans? It has a 100% glyph coverage, it is well hinted, and readable even at small sizes. If you want something more fancy/artistic, have a look at Noto Serif.
The alee-fonts don't look very well balanced to me, so beyond good glyph coverage I don't think it is a good choice.
Second choice after Noto Sans and Serif would be Baekmuk Gulim and Baekmuk Batang, which look well balanced, though have less glyph coverage and are less readable at small sizes than Noto Sans.
Anyway, we can discuss the "perfect" font for some more weeks, while users end up with completely broken fonts. Or we can just use a sensible default, which can overridden locally any time.
The point is that it's your preference, and hard-coding your favorite in a random place is no good implementation in general.
OTOH, noto-fonts should be installed as default and enabled as the preferred font via fontconfig if user installs the system with ko locale. So, practically seen, using this font is no problem, per se.
Actually, the bug surfaced because zypper (or installer) doesn't pick up all matching fonts with scalable-ko-fonts but only the first alphabetic one (supposedly). If we fix this in the zypper / installer side, we don't need such a hack. But, it's a harder way and may bring other problems.
So, I think we can go for this way -- adding a Recommends noto-ko-fonts in this particular case. But, then a comment line is needed so that reader can understand why this specific one is put there, at least.
Should only one font package provide "scalable-ko-fonts"?
Noto Sans CJK KR is now default font for the ko locale (when LC_CTYPE is ko). https://github.com/openSUSE/fonts-config/blob/master/59-family-prefer-lang-specific.conf#L254
However, the font is not set as an alias sans-serif. So it might not be selected if some other Korean fonts are installed when LC_CTYPE is other than ko: https://github.com/openSUSE/fonts-config/blob/master/60-family-prefer.conf#L92
I agree going this way.
Should only one font package provide "scalable-ko-fonts"?
Definitely no - its a virtual provides which all suitable (scalable, glyph coverage) should have.
Noto Sans CJK KR is now default font for the ko locale
Does not help when you want to write Korean and your locale is different.
The system is not installed with ko locale but en, see the linked openQA run.
As ibus-hangul is installed later, no suitable font is available. People may want to write Korean even if their locale is different.
"Noto Sans has a good coverage" - isn't this sufficient?
IMO, the test scenario is insufficient. If you want to use Korean -- at least with the input method or such -- user should enable the Korean language support on the system, not only installing only ibus-hangul If you did it on YaST, all needed stuff should have been installed, including noto fonts.
But it's a bit off-topic, and having a local workaround is acceptable.
Obviously @mschnitzer is not reviewing this, so I wonder why this package is assigned to him?
@darix - I think I answered your question, is anything missing? Otherwise, at least a "I am busy doing more important stuff" would be appreciated.
Sorry, I was away since end of November till today. I'm just seeing this right now. However, I'm not the maintainer of ruby2.6. I once packaged ruby2.6 together with darix, but I clearly don't have the experience to judge whether these changes are ok or not. I will remove myself as a maintainer - it probably has been set by accident. So @darix are you taking care of it?
Can anyone enlighten me whats holding this back?
Noone but darix won't touch it - and darix will have to explain his reasons
This is becoming ridiculous now - both the bug report and this SR have been ignored by the maintainers for 2 months ...
Friendly ping!
Another package which depends on the headers only, but comes early in the build process: rdma-core -> openmpi2 -> boost:base -> *
Thanks. Sounds good! An appropriate submitrequest would be appreciated and accepted. ;-)
HTMLPurifier is a vendor package in source from icingaweb2. And version 4.6.0 is meanwhile no more in source! Vendor package from icingaweb2 should be named after version from icingaweb and not about source from vendor-package itself.
Question again. What can i do?
PS: Now we are on 2.7.1 of icingaweb2.
I really do not like this changes as it will cause bug reports if a lot of pacakges will be installed at once due repeated call of mandb ... I really prefere transfiletriggerin and transfiletriggerpostun ... please note that the old solution had its reason as otherwise I had used post and preun scriplets to run mandb
This comment has been deleted