Search results for

Re: [opensuse-factory] boycott systemd

by Stefan Seyfried

Am 11.08.2014 um 10:04 schrieb Tomáš Chvátal: > Dne Po 11. srpna 2014 08:16:12, Stefan Seyfried napsal(a): >> Am 11.08.2014 um 07:53 schrieb Michal Kubecek: >>> On Sunday 10 of August 2014 06:25:01 Robert Schweikert wrote: >>>> Well, we have the best tool in the world to work on alternatives >>>> and/or derivative distributions, OBS. I have not seen anyone step up >>>> and do the work necessary. However, I do have to admit that I am >>>> certainly not aware of every project in OBS. >>> >>> Apparently you haven't tried that. If you did (as I did), you would find >>> how many subtle - and sometimes not so subtle - changes have been done >>> to packages not related to systemd at all which were not needed for >>> systemd but only break non-systemd systems. In some cases, just build a >>> package of "wrong" name gives you a hard error from OBS checks... >> >> Or actually "factory-maintainers" -- a bunch of people apparently who >> have decided they better maintain "my" project than I do -- accept >> submissions against "my" packages, which remove non-systemd stuff, which >> I kept in on purpose. >> >> Which leads to me actually mostly abandoning the vdr project right now. >> >> OT: can I just remove the factory-maintainers from the vdr project? I >> certainly have not added them, so removing them would most likely be >> futile... > > Factory maintainers team work based on maitainers inactivity. It's summer holiday time here in europe, and one week is barely inactivity. > You can avoid them doing any work just by reviewing SR#s or stating there that > they need to be redone in comment section. > > Usually the changes are reviewed if they are >1 week older without any > activity. In the review we only care for merging patches that work on > openSUSE:Factory and to extend if it works for supported openSUSE which are > 12.3+ (so systemd only). It does not help if the systemd-only version does no longer read the old config files. That's why I had the option to install the old init script (which works fine with systemd, at least that's what everyone was told when systemd was implemented). > The blame for having merged SR#s you didn't want is only for you. We simply > don't want people to sit and wait for 1 month + without any activity on their > patches. It is severly demotivating. And we still have such as for some areas > it is simply not obvious and maintainer does not care... It is at least as demotivating if submit requests from persons whose bugs in packages all over the distribution when they were adding systemd stuff in ways that was plain wrong and did not work at all and was clearly completely untested are accepted bypassing the one active maintainer who is actually using the package. I strongly object people to "fix" packages which are *not broken* and which they are most likely (or sometimes obviously) not using. Especialy very complex pieces of stuff like vdr. And this comment of the change log is plain wrong: +- Add backward symlink +- Provide and obsolete vdr-runvdr; the transition should be easier because now nobody is reading the settings from sysconfig/vdr. Fixing this is HARD. This is why I had not done this before, and why i kept the old init script instead. Just removing the working stuff and replacing it with broken stuff is easy. I could have done this from the start, it would have been easier. This is what I often see as the "systemd attitude": "look, I broke it, too bad, you have to fix it". It will be interesting to see who'll fix the bugzillas for that. Probably they will be "please check if this is still present in the current release" after 3 years and then be "resolved noresponse", because of course the reporter has moved on to somewhere where the maintainer cares. > And no you can't remove them from your project :) Ok, so be it. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

10 years, 6 months

Re: [opensuse-factory] How Leap and SLE's timetable overlap

by Richard Brown

> On 25 May 2016, at 01:24, Greg Freemyer <greg.freemyer(a)gmail.com> wrote: > > Nov 2016 - Release Leap 42.2 with 4.4 kernel > > Spring 2017 - Release the Leap 42.2 "advanced kernel" (ie. the 2017 > LTS kernel). > > Fall 2017 - Release Leap 42.3 with the 2017 LTS kernel (no longer > designated advanced). > > Fall 2017 - Drop all support for the 4.4 kernel when Leap 42.3 is released > > Spring 2018 - Release the 42.3 "advanced kernel" (ie. the 2018 LTS kernel) > > Spring 2018 - Drop 2017 LTS kernel support (when Leap 42.2 support is dropped). > > > The end result is that over the summer 2 kernels are supported: the > current LTS kernel and the previous year's LTS kernel. > > But during the winter only one kernel is supported. > > From the kernel team's perspective they may even be able to leverage > SLE kernel support at all times because they will have to support SLE > kernels longer than the 12 months I'm proposing. That assumes the SLE > will be supporting each of the annual LTS kernels. Greg, please consider the user impact of what you are proposing. Two kernels in the same distro? Users having to switch to one during the lifecycle of the distro? That complexity and that forced changing brings with it risk - new kernels break things for some people. Some people don't want to take those risks. Those are the people we make Leap for. Leap is never going to support the latest and greatest hardware. It's not meant to. It's meant to be a reliable, dependable, workhorse of a distribution that people can put their faith into. A more moderate pace of change,like the one we currently have, is the best way to accomplish that. For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the protocols existence the Kernel doesn't support it yet, we have Tumbleweed. You cannot have it both ways. If you want to leave life on the edge, and your hardware purchases suggest you do, then Tumbleweed is the best platform for you. You cannot crave stability - you're buying hardware so new that no software support is available. 4.6 is just the first version to add support for USB 3.1 Gen 2. There will be bugs. Things will not be stable for USB 3.1 Gen 2 for some kernel versions yet. And before you argue '3.1 Gen 2 is going to take over the world in 12 months, I'd like to point out that USB 3 came out in 2008 and took years before becoming ubiquitous. 3.1 is only just now appearing on new mainstream machines and even then that is Gen 1, fully supported stuff I can find ONE motherboard, a high end MSI gaming board with a Gen 2 card in it So even if they get it right first time and Kernel 4.6 has no USB 3.1 Gen 2 bugs, it's still a whole bunch of change for a very narrow benefit. We're not building Leap to cover every edge case. USB 3.1 Gen 2 is an edge case now, it will be in November, and I do not feel it's support is a compelling argument for playing loose and risk with the entire concept and purpose of what we're doing with Leap. Now, I am not saying that the SLE kernel will make sense for Leap 42.3. Just like we did for 42.1, we are in the position to make the right choice for us. We can talk about that next year, after 42.2's release, when we have very real facts to base our discussions on, such as the state of the upstream kernels at the time and our experience of them within Tumbleweed. But I am certain that choosing 4.4 sets us in a very good foundation for the future. Being an LTS kernel means we can be certain it will be well supported for the full lifespan of 42.2 and, if we choose to not do a kernel upgrade in 42.3, then we know that we still be on a very well supported, stable, LTS kernel. And I guess that's my point, right now, based on the information we have and the points raised to date, I am utterly convinced that the SLE 12 SP2 Kernel (4.4 with whatever backports are already there) is the correct choice for Leap 42.2 I'm open to debate on that point but I feel the arguments need to be stronger than the USB 3.1 Gen 2 case. I'm don't think it's too productive to worry too far into the future such as Leap 42.3 and beyond - that requires speculation or crystal balls, which aren't very useful, or time machines, which we don't even have support for in Tumbleweed yet ;) Sorry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 9 months

Re: [opensuse-factory] New Tumbleweed snapshot 20160625 released!

by Bjoern Voigt

Bjoern Voigt wrote: > Dominique Leuenberger wrote: >> Please note that this mail was generated by a script. >> The described changes are computed based on the x86_64 DVD. >> The full online repo contains too many changes to be listed here. >> >> Please check the known defects of this snapshot before upgrading: >> https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… >> >> Packages changed: >> [...] >> libqt4 > After updating to latest Tumbleweed snapshot 20160625 my MythTV 0.27.6 > installation does not work anymore. > > MythTV 0.27.6 is compiled against libqt4. > > I found this messages in logs: > > # mythtv-setup -v database > [...] > 2016-06-28 12:28:29.681915 I Starting process manager > 2016-06-28 12:28:29.683507 I Starting IO manager (read) > 2016-06-28 12:28:29.683545 I Starting IO manager (write) > 2016-06-28 12:28:29.683599 I Starting process signal handler > QSqlDatabase: QMYSQL driver not loaded > QSqlDatabase: available drivers: QSQLITE > 2016-06-28 12:28:29.784012 I Clearing Settings Cache. > 2016-06-28 12:28:29.790650 I Database connection created: DBManager0 > [...] > 2016-06-28 12:28:29.982854 E MSqlDatabase::OpenDatabase(), db > object is not valid! > > Why QMYSQL does not load? > > I checked libqt4, libqt4-sql, libqt4-sql-mysql and libmysqlclient18. > They are updated and have no dependency problems: > > # rpm -q libqt4 libqt4-sql libqt4-sql-mysql libmysqlclient18 > libqt4-4.8.7-4.1.x86_64 > libqt4-sql-4.8.7-4.1.x86_64 > libqt4-sql-mysql-4.8.7-4.1.x86_64 > libmysqlclient18-10.0.22-3.2.x86_64 > # rpm -V libqt4 libqt4-sql libqt4-sql-mysql libmysqlclient18 > > Recompiling mythtv 0.27.6 also did not help. I verified the problem with MythTV 0.27 from Packman. Same problem. Also I found a small testing program: qtmain.cpp: #include <QtGui/QApplication> #include <QTextCodec> #include <QObject> #include <QtSql/QSqlDatabase> #include <QStringList> #include <QtSql/QSqlQuery> #include <QtSql/QSqlRecord> #include <QVariant> #include <iostream> int main(int argc, char *argv[]) { QSqlDatabase DB; std::cout <<std::endl<< "try connect MYSQL "<< std::endl; try { DB = QSqlDatabase::addDatabase( "QMYSQL"); } catch(...) { std::cout << "fatal error"<< std::endl; } std::cout << "add database"<< std::endl; DB.setDatabaseName( "wdtdemo" ); DB.setUserName( "root" ); DB.setPassword( "password_for_root" ); std::cout << "1"<< std::endl; DB.setHostName( "" ); std::cout << "try to connect"<< std::endl; if (DB.open()) { std::cout << "QMYSQL correctly connected "<< std::endl; } else { std::cout << "QMYSQL not connected "<< std::endl; } QApplication a(argc, argv); QTextCodec::setCodecForCStrings(QTextCodec::codecForName("UTF-8")); return a.exec(); } qtmain.pro: ###################################################################### # Automatically generated by qmake (2.01a) Di Jun 28 13:04:18 2016 ###################################################################### QT = core gui sql TEMPLATE = app TARGET = DEPENDPATH += INCLUDEPATH += # Input SOURCES += qtmain cpp It only finds QSQLITE, but not QMYSQL and not PostgreSQL. # qmake # make g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_WEBKIT -DQT_NO_DEBUG -DQT_SQL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtSql -I/usr/include -I. -I. -o qtmain.o qtmain.cpp g++ -Wl,-O1 -o qtmain qtmain.o -L/usr/lib64 -lQtSql -L/usr/lib64 -lQtGui -L/usr/X11R6/lib -lQtCore -lpthread # ./qtmain try connect MYSQL QSqlDatabase: QMYSQL driver not loaded QSqlDatabase: available drivers: QSQLITE QSqlDatabase: an instance of QCoreApplication is required for loading driver plugins add database 1 try to connect QMYSQL not connected Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 8 months

Re: [opensuse-factory] Re: Can I disable gpg check for rpms stored locally

by Roman Bysh

On 09/10/2016 06:00 PM, Malcolm wrote: > On Sat 10 Sep 2016 04:44:28 PM CDT, Roman Bysh wrote: > > > On 09/10/2016 04:39 PM, Roman Bysh wrote: > >> > >> > >> On 09/10/2016 04:31 PM, Roman Bysh wrote: > >>> > >>> > >>> On 09/10/2016 10:37 AM, Ken Schneider wrote: > >>>> On 09/09/2016 08:28 PM, Carlos E. R. wrote: > >>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>> Hash: SHA256 > >>>>> > >>>>> > >>>>> > >>>>> El 2016-09-09 a las 19:29 -0400, Roman Bysh escribió: > >>>>> > >>>>>> > >>>>>> Every time I install my rpms (stored locally) using Yast, I get > >>>>>> two pop up messages > >>>>>> telling me they're broken and that my system can be broken if > >>>>>> installed. > >>>>>> > >>>>>> Is there a setting where I can disable the pop up warnings for my > >>>>>> local repository? > >>>>> > >>>>> I use a local directory as local repo, and I get no warning, but > >>>>> I use 13.1. Do you mean the check for the repo itself, of the > >>>>> check for individual packages? The later should not be affected. > >>>>> > >>>>> > >>>> I also use a local repo and get no such warnings. I would suggest > >>>> removing the repo and add it again to see if the errors go away. > >>>> > >>> I'll try it and get back. > >> Follow Up > >> > >> I deleted dmg2img and then reinstalled it. > >> I still get a message that it's broken, integrity check has failed. > >> > >> Error: INVALID:dmg2img-1.6.5-2.1.x86_64 (Local-Repository): > >> Signature verification failed [4-Signatures public key is not > >> available] Header V3 DSA/SHA1 Signature, key ID 91e6e64b: NOKEY > >> Header SHA1 digest: OK (d1905caf4f9dcf4daae492002191e24dc9f1b150) > >> MD5 digest: OK (ecf23a5ebc35779ce51f066436259bef) > >> V3 DSA/SHA1 Signature, key ID 91e6e64b: NOKEY > >> > > This message never popped up before openSUSE Leap and the more recent > > builds of Tumbleweed this year. > > > > I think I'll make a bug report. > Hi > AFAIK see the key has expired.... > > gpg --recv-keys 91e6e64b > > gpg: requesting key 91E6E64B from hkp server keys.gnupg.net > gpg: key 91E6E64B: public key "home:enzokiel OBS Project <home:enzokiel@build.opensuse.org>" imported > gpg: no ultimately trusted keys found > gpg: Total number processed: 1 > gpg: imported: 1 > > gpg --fingerprint 91e6e64b > > pub 1024D/91E6E64B 2008-01-22 [expired: 2010-04-01] > Key fingerprint = 8514 7276 1146 DB32 B2D4 DB1D E4DA DB32 91E6 E64B > uid [ expired] home:enzokiel OBS Project <home:enzokiel@build.opensuse.org> > > Get the version from the filesystem repo instead? > Understood. However, I'm getting these error with any rpm stored locally that I install using Yast2. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 6 months

Re: [opensuse-factory] Can I disable gpg check for rpms stored locally

by Patrick Shanahan

* Roman Bysh <rbtc1(a)rogers.com> [09-10-16 17:30]: > > On 09/10/2016 04:50 PM, Roman Bysh wrote: > > > > > > On 09/10/2016 04:44 PM, Roman Bysh wrote: > > > > > > > > > On 09/10/2016 04:39 PM, Roman Bysh wrote: > > > > > > > > > > > > On 09/10/2016 04:31 PM, Roman Bysh wrote: > > > > > > > > > > > > > > > On 09/10/2016 10:37 AM, Ken Schneider wrote: > > > > > > On 09/09/2016 08:28 PM, Carlos E. R. wrote: > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > > Hash: SHA256 > > > > > > > > > > > > > > > > > > > > > > > > > > > > El 2016-09-09 a las 19:29 -0400, Roman Bysh escribió: > > > > > > > > > > > > > > > > > > > > > > > Every time I install my rpms (stored locally) using Yast, I get two > > > > > > > > pop up messages > > > > > > > > telling me they're broken and that my system can > > > > > > > > be broken if installed. > > > > > > > > > > > > > > > > Is there a setting where I can disable the pop up warnings for my > > > > > > > > local repository? > > > > > > > > > > > > > > I use a local directory as local repo, and I get no > > > > > > > warning, but I use > > > > > > > 13.1. Do you mean the check for the repo itself, of the check for > > > > > > > individual packages? The later should not be affected. > > > > > > > > > > > > > > > > > > > > I also use a local repo and get no such warnings. I > > > > > > would suggest removing the repo and add it again to see > > > > > > if the errors go away. > > > > > > > > > > > I'll try it and get back. > > > > Follow Up > > > > > > > > I deleted dmg2img and then reinstalled it. > > > > I still get a message that it's broken, integrity check has failed. > > > > > > > > Error: INVALID:dmg2img-1.6.5-2.1.x86_64 (Local-Repository): > > > > Signature verification failed [4-Signatures public key is not > > > > available] > > > > Header V3 DSA/SHA1 Signature, key ID 91e6e64b: NOKEY > > > > Header SHA1 digest: OK (d1905caf4f9dcf4daae492002191e24dc9f1b150) > > > > MD5 digest: OK (ecf23a5ebc35779ce51f066436259bef) > > > > V3 DSA/SHA1 Signature, key ID 91e6e64b: NOKEY > > > > > > > This message never popped up before openSUSE Leap and the more recent > > > builds of Tumbleweed this year. > > > > > > I think I'll make a bug report. > > The integrity check happens for individual packages that are stored in a > > folder > > in my /home/username/local-repository folder. > Here is the bug report. https://bugzilla.opensuse.org/show_bug.cgi?id=998294 Please consider some judicious trimming. It is really *not* beneficial to see the same lines repeated, and repeated, and ..... Not pleasing either. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 6 months

Re: [opensuse-factory] Re: Tumbleweed and Realtek based wifi nics

by Larry Finger

On 10/02/2016 07:19 PM, Moby wrote: > > > On 10/02/2016 05:54 PM, Larry Finger wrote: >> On 10/02/2016 05:48 PM, Moby wrote: >>> >>> >>> On 10/02/2016 03:12 PM, Moby wrote: >>>> TOSHIBA Satellite L775D/TKBSS laptop has severe packet drop with Realtek >>>> chipset based wifi cards. Builtin wifi based on Realtek RTL8188CE and a >>>> usb wifi adapter based on a different Realtekchip set both show heavy >>>> packet loss (around 60%). Nothing gets logged anywhere. Builtin >>>> Ethernet works fine. >>>> >>>> I know the wifi infrastructure is good since many other laptops work >>>> fine. One of the other laptops is running the same version of >>>> Tumbleweed (same kernel version etc but 32 bit - the problematic machine >>>> is 64 bit) but a different (Broadcom) chipset based wifi also works >>>> great. >>>> >>>> The machine is now running kernel 4.7.5-1-default, and I have installed >>>> each and every kernel update to show up in the Tumbleweed repos fairly >>>> faithfully. The problem with Realtek wifi started about 3 or so kernel >>>> updates ago. >>>> >>>> Is anyone else seeing problems with Tumbleweed and Realtek chipset >>>> wifis? Any help pointing towards more diagnostic tools or solutions >>>> will be much appreciated. >>>> >>>> >>>> >>>> >>> I downgraded the kernel to 4.6.0-1-default, which had a known realtek >>> wifi bug >>> that is fixed with >>> rtlwifi-quickfix-kmp-default-4.6_k4.6.0_1-3.1.x86_64.rpm. >>> Installing 4.6.0-1-default with this one-off patch seems to have improved >>> matters, I now suffer about 25% packet loss as opposed to about 65%. >>> >>> I could not go to any lower versions of the kernel since they throw up >>> all other >>> kinds of errors, which I assume are due to userland all being updated >>> (e.g. >>> wpa_supplicant etc). >>> >>> This very much appears to be a kernel issue with realtek chipsets. I >>> got yet >>> another USB wifi adapter (belkin) to try, but it is also based on a >>> realtek >>> chipset and has the same issues. >> >> If you can bisect the kernel and point to a particular commit that >> causes the increased packet loss, that would be very helpful. I know of >> no changes to any of the Realtek drivers that would cause these kinds of >> problems. >> >> Larry >> > > Thanks Larry - I have some idea of bisecting software, but no idea in regards to > the Tumbleweed. Where can I find the various commits/versions to test as part > of the bisection? If openSUSE has a git repository for its kernels, I am not aware of its location. Perhaps someone will come up with that information. You could clone the mainline repository from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git. Every change included in 4.7.X will be in that code. I would use the 4.7.5 configuration to build kernel 4.8 that is in that repo and test it. If you still get the packet loss, then use the commands 'git bisect start drivers/net/wireless/realtek/rtlwifi/', 'git bisect bad', and 'git bisect good v4.6'. Change that last one to whatever version you think is good. That bisection will have roughly 5 steps to finish and should not take too long, even with the full configuration used in distribution kernels. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 years, 5 months

[opensuse-factory] New Tumbleweed snapshot 20190306 released!

by Dominique Leuenberger

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/openSUSE:Submitting_bug_reports Packages changed: glibc glibc libstorage-ng (4.1.95 -> 4.1.96) patterns-yast (20181130 -> 20190228) rzip virt-manager yast2 (4.1.56 -> 4.1.60) yast2-configuration-management (4.1.5 -> 4.1.6) yast2-control-center (4.1.6 -> 4.1.7) yast2-installation (4.1.37 -> 4.1.39) yast2-iscsi-client (4.1.5 -> 4.1.6) yast2-network (4.1.42 -> 4.1.43) yast2-packager (4.1.29 -> 4.1.30) yast2-ruby-bindings (4.1.2 -> 4.1.4) yast2-storage-ng (4.1.68 -> 4.1.70) yast2-users (4.1.9 -> 4.1.10) === Details === ==== glibc ==== - regex-read-overrun.patch: fix read overrun (CVE-2019-9169, bsc#1127308, BZ #24114) - ldconfig-concurrency.patch: Avoid concurrency problem in ldconfig (bsc#1117993, BZ #23973) ==== glibc ==== Subpackages: glibc-devel glibc-extra glibc-info glibc-locale glibc-locale-base nscd - regex-read-overrun.patch: fix read overrun (CVE-2019-9169, bsc#1127308, BZ #24114) - ldconfig-concurrency.patch: Avoid concurrency problem in ldconfig (bsc#1117993, BZ #23973) ==== libstorage-ng ==== Version update (4.1.95 -> 4.1.96) Subpackages: libstorage-ng-lang libstorage-ng-ruby libstorage-ng1 - merge gh#openSUSE/libstorage-ng#621 - handle entries in crypttab whose block device do not exist (bsc#1123342) - added unit test - added documentation - added explanation - renamed variable - 4.1.96 ==== patterns-yast ==== Version update (20181130 -> 20190228) Subpackages: patterns-yast-x11_yast patterns-yast-yast2_basis patterns-yast-yast2_install_wf - Added yast2-alternatives to the "yast2_basis" pattern (opensuse only) (bsc#1125040). - 20190228 ==== rzip ==== - Modernise spec file - Install license ==== virt-manager ==== Subpackages: virt-install virt-manager-common - Temporarily disable Xen PVH support until feature is more usable (bsc#1125889) virtinst-add-pvh-support.patch ==== yast2 ==== Version update (4.1.56 -> 4.1.60) Subpackages: yast2-logs - added "Modify" button label (related to gh#yast/yast-yast2#713) - 4.1.60 - Added command line support also for the other Report module methods (related to bnc#1127685) - 4.1.59 - Fixed a failing testsuite, the Report.LongError used in the global exception handler did not support the command line mode (related to bnc#1127685) - 4.1.58 - bnc#1127685 - made Report module long message reporting popups adjustable - 4.1.57 ==== yast2-configuration-management ==== Version update (4.1.5 -> 4.1.6) - Fix $visibleIf condition evaluation when the left value is "false" or when the path is absolute (bsc#1127402). - 4.1.6 ==== yast2-control-center ==== Version update (4.1.6 -> 4.1.7) Subpackages: yast2-control-center-qt - Introduce very effective fallback for icons (boo#1127245) - 4.1.7 ==== yast2-installation ==== Version update (4.1.37 -> 4.1.39) - Do not write the displaymanager value (part of bsc#1125040). - 4.1.39 - Respect Textmode=1 when installing over SSH with a DISPLAY (bsc#1047470) - 4.1.38 ==== yast2-iscsi-client ==== Version update (4.1.5 -> 4.1.6) - fixed parsing of iscsiadm -m node -P 1 (bsc#1121806) - 4.1.6 ==== yast2-network ==== Version update (4.1.42 -> 4.1.43) - Fixed "can't modify frozen String" crashes (related to bsc#1125006 and gh#yast/yast-ruby-bindings#228) - 4.1.43 ==== yast2-packager ==== Version update (4.1.29 -> 4.1.30) - fix showing help text for product license (bsc#1126491) - 4.1.30 ==== yast2-ruby-bindings ==== Version update (4.1.2 -> 4.1.4) - Always return frozen strings from the translation functions, make the results unified (related to bsc#1125006) - 4.1.4 - bnc#1127685 - Internal error message popup is scaled according to its content - 4.1.3 ==== yast2-storage-ng ==== Version update (4.1.68 -> 4.1.70) - Fixed "can't modify frozen String" crashes (related to bsc#1125006) - Fixed missing translation (bsc#1127181) - 4.1.70 - Translates the filesystem roles properly (bsc#1127756). - 4.1.69 ==== yast2-users ==== Version update (4.1.9 -> 4.1.10) - Removed "btrfs_subvolume" from user default values (bsc#1125779) - Added AutoYaST support for home Btrfs subvolumes. - 4.1.10 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 years

Re: [opensuse-factory] Re: Mesa for Tumbleweed

by Takashi Iwai

At Thu, 03 Apr 2014 18:26:06 +0200, Tobias Klausmann wrote: > > > On 03.04.2014 17:45, Greg KH wrote: > > On Thu, Apr 03, 2014 at 12:12:36PM +0200, langkamp(a)tomblog.de wrote: > >>> Greg KH <gregkh(a)linux.com> hat am 2. April 2014 um 00:37 geschrieben: > >>> > >>> > >>> On Wed, Apr 02, 2014 at 12:25:04AM +0200, Tobias Klausmann wrote: > >>>> (snip) > >>>>>> I'd suggest: > >>>>>> > >>>>>> X11:XOrg for Mesa 10.1 > >>>>>> https://build.opensuse.org/package/show/X11:XOrg/Mesa > >>>>> $ osc whatdependson openSUSE:13.1 Mesa standard i586 | wc -l > >>>>> 2003 > >>>>> > >>>>> Hah, yeah right, I'm not going to do that, sorry. > >>>>> > >>>>>> devel:tools:compiler for llvm 3.4 > >>>>>> https://build.opensuse.org/package/show/devel:tools:compiler/llvm > >>>>> I can add this, but is is really used by anyone? > >>>> It is used to compile parts of/for Mesa, but with you not adding Mesa, it > >> is > >>>> more or less pointless to add it. > >>> Ok, I'll go remove it then, thanks. > >>> > >>> greg k-h > >> > >> Thanks greg for looking into this. I understand that it's too much work? > > It means I would have to have _all_ of 13.1 in the Tumbleweed repo. > > Things would be constantly rebuilding. I would have to do a lot more > > work, and Tumbleweed would be a stand-alone distro image at that point > > in time. > > Hmm that is not right, Tumbleweed would need a subset of the X11:XOrg > packages. > The smallest amount of pakages would be something like: > Mesa > xorg-x11-server > xf86-{...} drivers > libdrm (if there is not the newest version in the 13.1 standard repos) > > llvm > > > > > And that's something I've said I was NOT going to do at all every time > > this has come up in the past. > > > >> Maybe the work would seem worthwhile when we know how many people would like > >> this update. So I opened a request on openFATE: > >> > >> https://features.opensuse.org/317173 > >> > >> I'll be back when a "reasonable" number of supporters votes this up :) > > So, it will somehow, because people want this, become more "managable"? > > That's not how things work, sorry. > > > > If you want the latest Mesa, try it in your own private repo and let me > > know how it goes. Or use the X11:XOrg repo. But given that this is a > > low-level library, with almost everything depending on it one way or the > > other, it is going to be tough going, sorry. > > Contrary to your prediction it is always going very smooth, at least > with upstream stable builds. > Not saying you have to do it, but it is not as much work as you seem to > think it is. I guess the same, too. Although the updating these X and Mesa libraries will trigger the massive rebuilds of packages at each update (I laughed when I looked at zsh being listed in osc whatdependson for Mesa), the impact wouldn't be too severe. There are little applications that communicate with Mesa directly, and the rebuilds would be triggered mostly by the upper layer like cairo, qt3, or tetex; i.e. these triggers might be even skipped, too. Of course, the fact that it'll result in massive rebuilds remains, so I don't mean to urge Greg for taking them to Tumbleweed immediately. But, we may take a look beyond the shocking numbers shown there. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

10 years, 11 months

Re: [opensuse-factory] Re: [opensuse-kernel] libsigsegv build fail with kernel 3.18.3

by Takashi Iwai

Linus, the commit [320b2b8de126: mm: keep a guard page below a grow-down stack segment] seems resulting in a regression with libsigsegv. Looking at the change, it's pretty obvious why it breaks; libsigsegv expects SIGSEGV explicitly for the scenario the patch touches. (FWIW, a failing test code to be found at: http://git.savannah.gnu.org/cgit/libsigsegv.git/tree/tests/stackoverflow1.c ) This is a case giving us a dilemma. Of course, we can "fix" libsigsegv to handle SIGBUS gracefully. OTOH, this can be seen as a user-space regression we'd like to avoid usually. What do you think? thanks, Takashi At Tue, 27 Jan 2015 14:08:04 +0100, Dimstar / Dominique Leuenberger wrote: > > Jan, > > On Tue, 2015-01-27 at 13:58 +0100, Jan Engelhardt wrote: > > On Tuesday 2015-01-27 13:40, Michal Marek wrote: > > >On 2015-01-27 13:24, Dimstar / Dominique Leuenberger wrote: > > >> > > >> The test suite is intentionally 'badly written' and is supposed to cause > > >> sigsegv for various cases. The current tests failing are around stack > > >> overflows. Up to kernel 3.18.1, those reported SIGSEGV back, but it > > >> seems nowadays we get a SIGBUS (which is not in scope of a library > > >> called libSIGSEGV to be caught). > > > > > >This is probably commit fee7e49d (mm: propagate error from stack > > >expansion even for guard page). > > > > Relatedly interesting: > > > > commit 320b2b8de12698082609ebbc1a17165727f4c893 > > Author: Linus Torvalds <torvalds(a)linux-foundation.org> > > Date: Thu Aug 12 17:54:33 2010 -0700 > > > > mm: keep a guard page below a grow-down stack segment > > > > This is a rather minimally invasive patch to solve the problem of the > > user stack growing into a memory mapped area below it. Whenever we fill > > the first page of the stack segment, expand the segment down by one > > page. > > > > Now, admittedly some odd application might _want_ the stack to grow down > > into the preceding memory mapping, and so we may at some point need to > > make this a process tunable (some people might also want to have more > > than a single page of guarding), but let's try the minimal approach > > first. > > > > Tested with trivial application that maps a single page just below the > > stack, and then starts recursing. Without this, we will get a SIGSEGV > > _after_ the stack has smashed the mapping. With this patch, we'll get a > > nice SIGBUS just as the stack touches the page just above the mapping. > > > > Whether it ought to be SIGBUS or SIGSEGV, is perhaps a matter of debate. > > WP has to say about it: > > That one sounds actually very much like the kernel changes this behavior > intentionally and 100% conscious. > > > """a process is trying to access memory that the CPU cannot > > physically address: an invalid address for the address bus, > > hence the name. [...] segmentation faults, which occur > > primarily due to memory access violations: problems in the > > logical address or permissions.""" > > > > The guard page, I would say, is an access violation protection, > > rather than something unadressable (like unaligned words on certain > > CPUs). > > Indeed, semantics. Somebody should ask Linus about it :) > > IF this is to remain SIGBUS, then I don't think it's (anymore) in scope > of libsigsegv to catch it and offer a handler for it, in which case > removing the test would be the logical step; but I don't know what all > else we might break with that. > > osc whatdependson gives me this short list: > libsigsegv : > cedilla > clisp > emacs-auctex > maxima > texlive > wxMaxima > xindy > yodl > > Thoughts anybody? > > > > > -- > Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> > > -- > To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org > -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

10 years, 1 month

Re: Fwd: [opensuse-factory] Re: [opensuse-packaging] Frustration with mongodb

by Boris Manojlovic

submitted SR to server:database, with its dependencies newer scons and python*-Cheetah3 On Fri, Dec 22, 2017 at 11:38 PM, Boris Manojlovic <boris(a)steki.net> wrote: > so here is first "working" version config is broken so package for now > can't work without changing conf file > https://build.opensuse.org/package/show/home:bmanojlovic:branches:server:da… > version is 3.6.0 > > On Thu, Dec 7, 2017 at 11:56 AM, Boris Manojlovic <boris(a)steki.net> wrote: >> i am trying to port changes in main repo but that takes time (and >> probably there will be new release for factory based on that work) >> https://github.com/mongodb/mongo/compare/master...bmanojlovic:python3 >> >> On Wed, Dec 6, 2017 at 3:54 PM, Richard Palethorpe <rpalethorpe(a)suse.de> wrote: >>> Hello Boris, >>> >>> Boris Manojlovic writes: >>> >>>> I have "ported" all python scripts to python3 which is now forced with >>>> latest scons, which was annoying but not that problematic part >>>> other issue is with openssl 1.1 which i have seen patches from fedora >>>> people on mongo JIRA >>>> so if someone else can look to incorporate third party asio library please do >>>> my package "fixes" are at >>>> https://build.opensuse.org/package/view_file/home:bmanojlovic:branches:serv… >>>> >>> >>> Have you submitted this to upstream? I don't see any reason they would >>> not accept it unless you are unwilling to sign the contributor >>> agreement. >>> >>>> >>>> On Tue, Dec 5, 2017 at 9:57 AM, Richard Palethorpe <rpalethorpe(a)suse.de> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Santiago Zarate writes: >>>>> >>>>>> You're using MongoDB... This might be of your interest >>>>>> >>>>> >>>>> Yes, thanks. I can add this to the long list of obstacles I have to get >>>>> over to do some data analyses. :-p >>>>> >>>>>>> >>>>>>> I'm not interested in maintaining it, I just have to use it (and >>>>>>> apparently, nobody was using it, considering how many issues I found >>>>>>> when I tried to use it during last hackweek) :( >>>>>> Delete request has been alrady filled (see [1]), unless someone steps >>>>>> in I will also disable building in devel project. >>>>> >>>>> I have no idea who is saying what in this conversation, but I am using >>>>> MongoDB for generating kernel reports, which some of you may have read: >>>>> >>>>> https://gitlab.suse.de/rpalethorpe/srd >>>>> https://openqa.suse.de/group_overview/116#comment-78755 >>>>> >>>>> This is still an experiment, and I am not sure MongoDB is actually the >>>>> right tool, but I can take over MongoDB's maintainership for the time being. >>>>> >>>>> -- >>>>> Thank you, >>>>> Richard. >>>>> -- >>>>> To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org >>>>> To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org >>>>> >>> >>> >>> -- >>> Thank you, >>> Richard. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 years, 2 months

openSUSE Factory search results for query "reproducible-builds"