openSUSE Factory June 2018

factory@lists.opensuse.org

100 participants
65 discussions

[opensuse-factory] Too many packages to process
by Vojtěch Zeisek 12 Mar '21

12 Mar '21

I'm not sure, if this is bug or feature... After few days, update applet (TW, KDE) says there are 6843 new updates (TeX, R, ... ;-). When I click to "Install updates" error "Too many packages to process (6843/5200)" appears. Zypper handles it well. Is it worth of bug report? To b.o.o? Yours, V. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/

8 10

[opensuse-factory] [SOLVED] ssh-agent problems with XFCE / gnome-keyring-daemon
by Stefan Seyfried 25 Sep '18

25 Sep '18

Hi all, After a TW update in the last few weeks, ssh with ssh-agent did no longer work with my established setup. (I did not verify the problem with a pristine user account, though). I have set up my system (a loooong time ago... ;)) so that the ssh key is stored somehow in gnome-keyring-daemon and gets unlocked upon login. The ssh-agent knows the key: seife@strolchi:~> ssh-add -l 1024 SHA256:96ejSSf7kXLZRWhEE4oJUk20+RukUpSJOu4elrVABCU seife@strolchi (RSA) ...but it did not work: seife@strolchi:~> ssh server sign_and_send_pubkey: signing failed: agent refused operation Password: If I now refreshed the agent with "ssh-add", and entered my passphrase, then ssh without password did work. The journal showed the following: Apr 08 18:28:41 strolchi gnome-keyring-daemon[1868]: the /usr/bin/ssh-add command failed: Child process exited with code 1 Apr 08 18:28:41 strolchi gnome-keyring-daemon[1868]: ssh_askpass: exec(/usr/lib/gcr-ssh-askpass): No such file or directory So the solution was to install the gcr-ssh-askpass package (which provides /usr/lib/gcr-ssh-askpass) and now everything is working as before. Hope this helps someone ;-) -- 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

13 27

[opensuse-factory] Leap 15.0 - Bluetooth - Failed to change profile to a2dp_sink
by Linux Kamarada 29 Aug '18

29 Aug '18

Hi, everyone! My laptop is an Acer Aspire E15 with a built-in Bluetooth 4.0 adapter, namely Qualcomm Atheros Bluetooth 4.0 (ID 04ca:3014). I had to tweak Leap 42.3 for it work, here is a brief of what I did: https://forums.opensuse.org/showthread.php/524410-Qualcomm-Atheros-Bluetoot… Then I was using the kernel-default 4.13.6 and kernel-firmware from the Kernel:stable OBS repo. When I upgraded to Leap 15.0 Beta, I switched to the kernel-default 4.12.14 and kernel-firmware from the Leap 15.0 OSS repo. Now, even though my Bluetooth adapter is working, I am not able to pair with my headset (Philips SHB3060) using the A2DP profile. I installed Blueman, which gives some more control and information than GNOME's System Settings. Using Blueman, when I try to change my headset to the A2DP profile I get this: "Failed to change profile to a2dp_sink" I tested downloading Leap 15.0 GNOME Live, flashing it into an USB stick and booting from it. Bluetooth was not recognized at first, but blacklisting the acer_wmi module (see my forum post for details) and rebooting was enough. Then, Bluetooth worked normally (including switching to the A2DP profile). So, I believe it is a problem on my setup, not on Leap 15.0 itself, i.e. a clean install would be half of the solution, the another half blacklisting the acer_wmi module and rebooting. Any ideas on what changed and how I can make the A2DP profile work again? Thank you! Antonio The Linux Kamarada Project http://kamarada.github.io/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 5

[opensuse-factory] [Tumbleweed] krdc stopped working
by Achim Gratz 17 Aug '18

17 Aug '18

Unfortunately I can't say when exactly this happened, but while I was updating a Win7 laptop today I tried to log into it via krdc and that no longer works. At first I thought it was related to the new firewalld, but apparently there's some problem with Xcb? Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50790, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0 Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50800, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0 Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50801, resource id: 56623169, major code: 18 (ChangeProperty), minor code: 0 Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50802, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0 Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50803, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0 Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50804, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0 Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50805, resource id: 56623169, major code: 7 (ReparentWindow), minor code: 0 Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50806, resource id: 56623169, major code: 6 (ChangeSaveSet), minor code: 0 Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50807, resource id: 56623169, major code: 2 (ChangeWindowAttributes), minor code: 0 Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50808, resource id: 56623169, major code: 10 (UnmapWindow), minor code: 0 Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 13

[opensuse-factory] Package 'xmonad' is not available in your repositories. Cannot reinstall, upgrade, or downgrade.
by Michal Suchánek 10 Aug '18

10 Aug '18

Hello, this looks like we have some haskell issue in Tumbleweed: > Package 'xmonad' is not available in your repositories. Cannot > reinstall, upgrade, or downgrade. Is there some more information somewhere? Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 3

[opensuse-factory] Mailinglist changes going forward
by Simon Lees 04 Aug '18

04 Aug '18

Hello everyone, Firstly I am cross posting this across a number of mailinglists because this post affects several, but I would ask that you keep your replies / feedback on the openSUSE project list as not to fragment discussion. It has been raised with the board by several members of the community that some of our mailinglists have not been working as effectively as we would like. As such and as raised in our annual discussion with the community during the conference, the board has decided to take a couple of steps that we hope will resolve these issues or that will at least be a starting point in resolving these issues. Firstly we have created a new opensuse-support(a)o.o mailing list, we as the board felt that in the transition from factory -> tumbleweed in particular the change in role for opensuse(a)o.o did not work well and in many cases there was an attitude that factory/tumbleweed issues should still be posted on the factory mailing list. As such we have created the support mailing list to help clarify these changes in policy that we don't believe worked when we tried to change them last time. In short we would like you to use opensuse-support(a)o.o whenever you require support whether it is for Tumbleweed, Leap (regardless of whether you are using a Leap beta or not) or any other project under the openSUSE umbrella. This brings us to the next issue, posting bugs / bug reports on mailing lists rather then bugzilla. This is a practice we would like to see stopped and we will be gently reminding people if they continue posting bugs on mailinglists, this especially includes if a package / application breaks when updating tumbleweed / leap (including beta's). We would ask that you search for your issue prior to reporting but in case you accidentally report a duplicate bug its easy for us to mark it as such, also if you report something that is intentional and not a bug it doesn't take long to mark it as such, so if in doubt file a bug rather then posting to a mailing list, there is useful information for filing bugs at the following links [1][2]. But if you are really stuck with trying to file your bug the friendly people at opensuse-support(a)o.o can support you through the process. The board hopes that with the changes outlined above the contents of the opensuse-factory(a)o.o will go back to just being general distro development discussion so if your post to openSUSE factory is something other then that think twice about where the more appropriate place to post is. The new tumbleweed snapshots will continue to be posted to factory but we would ask you do not reply to them in order to report issues / bugs. If a bug is reported that a package maintainer believes will cause significant issues for most tumbleweed users ie not being able to boot / login or severe data loss we still invite the maintainer to post a warning to opensuse-factory but such issues happen very rarely and as such we don't expect to see many such posts. The board has decided that it would like to see how well these changes work before deciding to add / remove / change openSUSE's mailing lists further. Although we have discussed several other possibilities that we could also try in the future. 1. https://en.opensuse.org/openSUSE:Bug_reporting_FAQ 2. https://en.opensuse.org/openSUSE:Submitting_bug_reports -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

13 19

[opensuse-factory] Advise needed on update-alternatives
by Axel Braun 15 Jul '18

15 Jul '18

Hi, we had some days ago a discussion on how to prevent postgres10 installation, as postgres96 is required: https://lists.opensuse.org/opensuse-factory/2018-06/msg00033.html The solution at that time, adding conflicts for postgres10, worked, but broke the openQA testing. So I went for adding update-alternatives --set postgresql /usr/lib/postgresql96 to the post-section of the spec-file This is objected by the maintenance team, see http://bugzilla.opensuse.org/show_bug.cgi?id=1096706 as '...consumer packages should be allowed to change the alternative selection for another package just so they can deal with them.' An idea would be to call postgres96 directly, but that is not an alternative, as the package just calls uri = postgresql://username:password@host:port/ and listens to what comes back. [setting up a different port for postgres96 is an expert solution that I would not consider here] As we have some more packages that cant deal with postgres10 (akonadi...) I feel that setting update-alternatives to postgres96 is a viable solution. Please share your opinion Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 4

[opensuse-factory] Announcing download.o.o access metrics
by Jimmy Berry 09 Jul '18

09 Jul '18

The full announcement can be viewed at release-tools.opensuse.org [1] along with images. Adding to the variety of metrics already captured at metrics.o.o [2], I have added download.o.o access metrics [3]. These metrics are sourced from the Apache access logs produced by the download.o.o machine. The goal of parsing the logs was to provide some insight into product adoption and long-term usage, in addition to overall project health. http://release-tools.opensuse.org/image/metrics.opensuse.org-access-stacked… The logs cover data from 2018-06-20 (and ingested daily going forward) to 2010-01-03 and amount to roughly 24TB of raw data. After exploring a few tools, like telegraf [4] (since commonly paired with influxdb [5]), they were found to be lacking in the speed department. For example, telegraf could not even handle 1000 entries per second [6] which would require well over three years to parse the data (reduced to over 6 months using concurrency if it supported that). Influxdb also couldn't handle the raw data (even a single day) as I had hoped to use it to perform the aggregations. As such, short of finding a magic tool which would still require customization for the custom log fields and meaning I opted to write a tool [7]. Given the speed sensitive nature of the problem I tested the primary scripting language of the openSUSE release tools, python, and compared it to PHP which I knew is generally faster. A simple test running a "starts with" on each log file line was an order of magnitude faster in PHP and the difference widened the more processing that was added. As such I opted for using PHP which was fast enough for the job while providing scripting language convenience. The end result was ~500,000 entries per second per core with full concurrency supported. Using this solution the last 8 years of data was processed and summarized in ~23 hours using 7 cores of an office machine. Going forward only the last day needs to be summarized which takes a minute or so. For those interested the 24TB was summarized to roughly 12GB of data which is then aggregated to roughly 8MB in influxdb. The 12GB lives on metrics.o.o in order to aggregate new days against previous data. The tool could be changed to drop data past the largest aggregation interval (ie a month), but if the aggregation algorithm is changed it would require the summary data. For further details about the tool or to review it see metrics/access directory [8] and README. One of the areas of interest was the number of beta systems Leap receives. The release schedule for the last three releases of Leap may be used to annotate the graphs by enabling the corresponding annotation at the top of the dashboard. The individual product series may also be isolated by clicking the product in the legend (ctrl+click to select more than one to isolate). The time range may also be changed using the tool in the top right (next to refresh button) or by selecting the area on graph (left click, hold, and drag to end of area desired). After focusing on 42.2 and 42.3 Beta phase we can see several thousand systems for both, but less for 42.3. It would be interesting to know if that reducing is a result of the rolling release model or something else. http://release-tools.opensuse.org/image/metrics.opensuse.org-access-beta.png One item to note is that, SUSE IPs (such as openQA) are not currently filtered out of the data and as such depending on usage may bump up the beta numbers. This is something I have not yet explored, but should not be too difficult to filter assuming an IP list or user-agent. The extreme long-tail of systems on old products is interesting and would seemingly indicate either neglected installs, laziness, or fear of updating, but given around a quarter of openSUSE systems are on releases beyond end-of- life [9] it is a bit concerning. :/ It may make sense to add an annotation containing product end of life dates. When compared to the last two versions of Leap_, Tumbleweed usage amounts to nearly half of one Leap release or a fifth of systems on supported releases. http://release-tools.opensuse.org/image/metrics.opensuse.org-access-stacked… For those interested, in more details there are three collapsed sections at the bottom of the dashboard which contain additional breakdowns of the data and output from the tool. For example, you can see the request counts by unique system by product. Although the averages are reasonable, the maximums are extremely high. Such maximums seemingly indicate either spam or heavy UUID reuse. Changing the aggregation frequency to day shows a very flat series that seemingly indicates automation. http://release-tools.opensuse.org/image/metrics.opensuse.org-access-average… Another area of interest is the steady increase in ipv6 traffic to roughly 10% of current unique systems. http://release-tools.opensuse.org/image/metrics.opensuse.org-access-unique-… The tool output includes the raw log size the metrics represent for the current time interval in addition to the number of invalid entries encountered. From reviewing a large number of the entries marked invalid they indeed are generally bogus, attack attempts, or incomplete requests. If we see a large decline in system counts and huge spike in invalid counts that should be clear there is a problem with the logs or tool going forward, but the most recent numbers, before the log format was broken, show the lowest invalid counts. The invalid log entry counts line up nicely with the big hole in the data. http://release-tools.opensuse.org/image/metrics.opensuse.org-access-invalid… If the time range is change to a year and the aggregation frequency (top left) is changed to a day we can very clearly see the correlation. It is even clear that the day before the big hole is the day the error was made as half the entries are invalid and log size is in between the day before and after. http://release-tools.opensuse.org/image/metrics.opensuse.org-access-log-siz… http://release-tools.opensuse.org/image/metrics.opensuse.org-access-invalid… Similarly, if the unique by product (stacked) is reviewed by day another pattern exposes itself. A consistent drop in unique counts by nearly 20%. In other words 20% of systems have weekends. :) http://release-tools.opensuse.org/image/metrics.opensuse.org-access-stacked… Also note that one can export the data as CSV in addition to viewing a graph full screen by clicking on the graph title. I look forward to receiving feedback and insight after people explore the data. While reviewing some of the raw log data I discovered a fair number of interesting and odd entries. I will summarize some of the highlights below (excluded from mailing list announcement). Enjoy! [1] http://release-tools.opensuse.org/2018/06/22/download.o.o-access-metrics.ht… [2] https://metrics.opensuse.org [3] https://metrics.opensuse.org/d/osrt_access/osrt-access [4] https://github.com/influxdata/telegraf [5] https://github.com/influxdata/influxdb [6] https://github.com/influxdata/telegraf/issues/3539 [7] https://github.com/openSUSE/openSUSE-release-tools/pull/1578 [8] https://github.com/openSUSE/openSUSE-release-tools/tree/master/metrics/ access [9] https://en.opensuse.org/Lifetime -- Jimmy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 13

[opensuse-factory] IDEA: NetworkManager by default for Desktops
by Richard Brown 05 Jul '18

05 Jul '18

Hi All, In both Leap & Tumbleweed we currently have the following logic for choosing which tool manages your network after installation "IF laptop AND NetworkManager is being installed THEN use NetworkManager, ELSE wicked" I've noticed an increasing trend that this can lead to confusion. Many users from other distributions expect NetworkManager on their desktops regardless of whether they are using a laptop or a desktop. GNOME expects NetworkManager by default and shows a rather unpleasant error when loading up the settings screen without it.[1] There are certainly classes of hardware where NetworkManager might be wanted that will never match "IF laptop" - eg. my personal Inter Compute Stick. And "IF laptop" is dependant on YaST correctly detecting you're using a laptop, which isn't 100% accurate, so occasionally even laptops might end up with wicked unexpectedly. I would like to propose a possible solution. It looks like we should be able to pin the choice of network tool to specific system role. I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default Server & Transactional will always have wicked by default Custom will keep the current "autodetect" behaviour, because we cant be sure that the environment that the user is installing has support for NetworkManager in this case. Whatever is setup "by default" during installation will be able to be changed in YAST after the installation, just like it is today. What do we all think? If there is strong support for this idea I think Ludwig is prepared to let me try and slip it in as a late feature for Leap 15, so please let your opinions be heard loudly and quickly either way. Regards, Richard [1] http://paste.opensuse.org/33301696 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

42 131

[opensuse-factory] NGINX Ingress Controller for Kubernetes - new packages
by Michal Rostecki 03 Jul '18

03 Jul '18

Hi, I recently submitted 17 packages to Factory and I would like to explain the purpose of those requests. Kubernetes has a concept of Ingress[0] which allows to expose a service running inside cluster to the external network. Although to be able to use that functionality, user needs to deploy the Ingress Controller[1]. The most popular, open source and upstream supported implementation is NGINX Ingress Controller[2]. I would like to bring the support of Ingress in Kubic and SUSE CaaSP projects, which means that we need a container image and packages for every component needed by NGINX Ingress Controller. That's why I started with submitting all needed packages to Factory. This is the list of submit requests I made: https://build.opensuse.org/request/show/617519 https://build.opensuse.org/request/show/617660 https://build.opensuse.org/request/show/617664 https://build.opensuse.org/request/show/617665 https://build.opensuse.org/request/show/617667 https://build.opensuse.org/request/show/617668 https://build.opensuse.org/request/show/617669 https://build.opensuse.org/request/show/617670 https://build.opensuse.org/request/show/617671 https://build.opensuse.org/request/show/617672 https://build.opensuse.org/request/show/617673 https://build.opensuse.org/request/show/617731 https://build.opensuse.org/request/show/617734 https://build.opensuse.org/request/show/617745 https://build.opensuse.org/request/show/617750 https://build.opensuse.org/request/show/617752 https://build.opensuse.org/request/show/617753 I would be very thankful for feedback and reviews. Cheers, Michal [0] https://kubernetes.io/docs/concepts/services-networking/ingress/ [1] https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-co… [2] https://github.com/kubernetes/ingress-nginx -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory June 2018