openSUSE Factory October 2018

factory@lists.opensuse.org

90 participants
60 discussions

[opensuse-factory] Re: Bug? Re: problem with static linking. of util-linux utils meant to be statically linkable...

by L A Walsh

On 10/6/2018 10:08 PM, Andrei Borzenkov wrote: > 07.10.2018 00:44, Linda Walsh пишет: >> So I should file this as a bug against factory or tumbleweed? There >> was some disagreement about whether or not they should be treated >> the same? > > For a start you should install glibc-devel-static or at least make it > clear that you are aware of its existence, have installed it and it did > not help. --- Sorry didn't forward this earlier. Was a bit put off by some bad attitude -- so far as to even call repetition of RedHat maintainer's, Karel Zak, confirming that his mount.static was indeed "fully static", as "fake news" (it did give warnings similar to those posted in os-fctry: ( ex: /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: > ./.libs/libmount.a(libmount_la-utils.o): in function `mnt_get_gid': > /dev/shm/util-linux-2.33-rc1/libmount/src/utils.c:614: warning: Using > 'getgrnam_r' in statically linked applications requires at runtime the > shared libraries from the glibc version used for linking ) but still linked down to 1 binary w/no runtime libs needed. Anyway, didn't feel like feeding the troll(s) so was going to wait until I had more information -- but did decide to forward the below from a few days ago. I suppose it might be of interest that 'gcc8' *doesn't* give the warnings about the config disallowing a fully static link (nor the other warnings as in the above example), yet still creates a non-static binary. -l -------- Original Message -------- Subject: Re: [ANNOUNCE] util-linux v2.33-rc1 Date: Sun, 07 Oct 2018 09:58:36 -0700 From: L A Walsh To: Bernhard Voelker CC: Karel Zak util-linux On 10/7/2018 7:57 AM, Bernhard Voelker wrote: > > $ zypper install glibc-devel-static > ---- Already had 2.27-4.1 installed, which I just bumped to 2.27-6.1. Same problem, unfortunately. *sigh* > make V=1 mount.static /bin/sh ./libtool --tag=CC --mode=link /usr/bin/gcc -fsigned-char -fno-common -Wall -Werror=sequence-point -Wextra -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wno-missing-field-initializers -Wredundant-decls -Wsign-compare -Wtype-limits -Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-parameter -Wunused-result -Wunused-variable -Wnested-externs -Wpointer-arith -Wstrict-prototypes -Wimplicit-function-declaration -Wdiscarded-qualifiers -I./libmount/src -fpic -march=native -pipe -O2 -all-static -fpic -march=native -pipe -O2 -Wl,--stats -o mount.static sys-utils/mount_static-mount.o libcommon.la libmount.la libtool: warning: complete static linking is impossible in this configuration libtool: link: /usr/bin/gcc -fsigned-char -fno-common -Wall -Werror=sequence-point -Wextra -Wmissing-declarations -Wmissing-parameter-type -Wmissing-prototypes -Wno-missing-field-initializers -Wredundant-decls -Wsign-compare -Wtype-limits -Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-parameter -Wunused-result -Wunused-variable -Wnested-externs -Wpointer-arith -Wstrict-prototypes -Wimplicit-function-declaration -Wdiscarded-qualifiers -I./libmount/src -fpic -march=native -pipe -O2 -fpic -march=native -pipe -O2 -Wl,--stats -o mount.static sys-utils/mount_static-mount.o ./.libs/libcommon.a ./.libs/libmount.a /home/tools/util-linux/util-linux-2.33-rc1/.libs/libblkid.a /home/tools/util-linux/util-linux-2.33-rc1/.libs/libuuid.a -lrt /usr/bin/ld: total time in link: 0.038702 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

[opensuse-factory] Re: [opensuse-packaging] Proposal to remove pyc/pyo from Python on TW

by Alberto Planas Dominguez

On Thursday, October 4, 2018 5:03:46 PM CEST Michael Ströder wrote: > On 10/4/18 4:52 PM, Alberto Planas Dominguez wrote: > > I created an small shim that replace the > > python3.7 binary to enable this cache prefix feature, to point it to /var/ > > cache/pycache/<username>, and I removed from the image all the python > > compiled code. > > The above sounds to me that compiled code goes into several > user-specific pycache directories. How does that save space? In two ways basically * The rpm is smaller * In the disk, for long services only one version of __pycache__ will be in / var/cache, the one under were the service is running Also /var/cache, by definition, can be clearer frequently, or even reside on RAM. But I agree that this point is relevant, as the user cache is in ~/.cache according to XDG, so this is another alternative. -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

[opensuse-factory] KMail: mailing lists not working

by Axel Braun

Hi, while talking about systray issues, there is another bug that hits me just again: https://bugs.kde.org/show_bug.cgi?id=378011 I have to manage a few mailing lists, they are defined as groups in Kontact address book. KMail is not properly resolving these groups, the address always ends up as mygroup@the_domain_set_in_KMail. When I create a small goup with just three entries it works, if I save a list of recipients (26 entries) as group and use the group name in the 'to' field it fails. Can it be depending on the number of recipients? Some years ago there was a bug that mailing lists with more than 87 entries failed reproducible. That was fixed more by chance than be purpose. Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

[opensuse-factory] sasl2-kdexoauth2 is probably missing an obsoletion

by Achim Gratz

One of the latest Tumbleweed updates apparently renamed the package sasl2-kdexoauth2-3 to sasl2-kdexoauth2, resulting in a conflict: S | Name | Type | Version | Arch | Repository --+--------------------+---------+-------------+--------+------------------ i | sasl2-kdexoauth2 | package | 18.08.1-2.1 | x86_64 | Tumbleweed-OSS i | sasl2-kdexoauth2-3 | package | 18.08.1-1.1 | x86_64 | (System Packages) It seems there is an obsoletion missing that would tell zypper to remove the old package. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

[opensuse-factory] YaST: highlights of development sprint 64

by Ancor Gonzalez Sosa

Lot of animated news in the latest development report from the YaST Team, including but not limited to: - Improvements in several areas of the Partitioner. - More informative Snapper. - Better integration of the new Firewall UI with AutoYaST. - Improvements in roles management and in the roles description. - Better support in YaST Firstboot for devices with no hardware clock, like Raspberry Pi. Check it out at https://lizards.opensuse.org/2018/10/09/yast-sprint-64/ Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

[opensuse-factory] The repository setup is broken...

by Roger Oberholtzer

I am fighting to build a LiDAR file access library on OBS. Aside from the general build issues, I get an error for a couple (but not all) repositories: openSUSE_Leap_15.0 and openSUSE_Leap_42.3. This is the error message: The repository setup is broken, build or publish not possible. I cannot see what it is unhappy about and there are no more details provided that I can see. The project is: https://build.opensuse.org/package/show/home:rogeroberholtzer/las (I'm posting here because the old OBS list is no more. And I really do not know where else to post this. If there is a better place, I can post there. But where might that be?) -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

[opensuse-factory] Proposal to remove pyc/pyo from Python on TW

by Alberto Planas Dominguez

Hi, As you know the Python packages are collecting the pyc/pyo precompiled binaries inside the RPM. This is mostly a good idea, as makes the first execution of the Python code faster, as is skipped the stage where the interpreter compile the .py code. But this also makes the Python stack a bit fat. Most of the time this is not a problem, but things are changing. We have JeOS and MicroOS, both minimal images (build with different goals and technology) that search for be small and slim. But we want to include a bit of Python in there, like salt-minion or cloud-init. And now the relative size of Python is evident. For Python 2.7 and 3.7 is possible to remove the pyc code from the system and instruct the interpreter to avoid the recreation of the pyc once the code is executed. The Python interpreter, by default, will compile and store the pyc in the disk for each `import`, but this behavior can be disable when we call Python. But this will make the initial execution of a big Python stack a bit slow, as the pyc needs to be recreated in memory for each invocation. The slowness can be relevant in some situations, so is better to not enable this feature. But in Python 3.8 there is a new feature in place, bpo-33499, that will recognize a new env variable (PYTHONPYCACHEPREFIX) that will change the place where __pycache__ is stored [2]. I backported this feature to 3.7 and create a JeOS image that includes salt-minion. I created an small shim that replace the python3.7 binary to enable this cache prefix feature, to point it to /var/ cache/pycache/<username>, and I removed from the image all the python compiled code. I decided salt-minion as saltsack is a relevant Python codebase. I needed to port to 3.7 150 python libraries to create the first PoC. The PoC works properly locally. I have yet some bits that I need to publish in the repo, but the general idea seems to work OK. I can also publish the gain on size for the ISO with the patch and without the patch, to have more data to compare. I also estimated some gains for different scenarios. For example in a normal TW installation: * Python 2.7 + 3.6 - pyc/pyc: 127M total - py: 109M total * Python 3.6 only - pyc/pyc: 91M total - py: 70M total Python pyc/pyo size is more than the py code size, so we can potentially half the size of the Python 3 stack. Maybe for a normal TW installation the absolute gain is not much (91M). But for other scenarios can be relevant, like in OpenStack Cloud, where the size of the Python code is big. I made some calculations based on all the different OpenStack services: * Python 2.7 OpenStack services - pyc/pyo: 1.2G total - py: 804M total Saving 1.2G each node is a more important number. So, my proposal is to remove the pyc from the Python 3 packages and enable the cache layer on Tumbleweed since Python 3.7. I do not know if do that by default or under certain configurations, as I am not sure how to that feature optional. Any ideas? Any suggestions? What do you think if I follow this path? Some ideas that I have are add a new %pycache-clean macro that will remove the __pycache__ from the RPM, add a new rpmlint check to make sure that there are not pyc for a python3 package, update the wiki and update the py2pack code to generate good python3 spec files for openSUSE. But if most of the community do not agree with this approach, I can drop the idea : ) [1] https://bugs.python.org/issue33499 [2] https://docs.python.org/3.8/whatsnew/3.8.html p.s: Sorry if the message is delivered two times, one from the .com account. My bad. -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

[opensuse-factory] Tumbleweed systray not configurable?

by Tom Hardy

Does anyone else see this? If I configure the systray by unchecking software updates on the general tab and marking notifications "shown" on the entries tab, then clicking on any icon is treated as if I clicked on the triangle icon, i.e., it shows hidden entries instead of showing details for the icon clicked on. At that point, if I reopen the configuration dialog and choose "entries", some or all of them will be missing. -- Tom Hardy <rhardy702(a)gmail.com> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

[opensuse-factory] New package menulibre for Factory approval

by Maurizio Galli

Dear All, I'm Maurizio and some of you may know me as MauG on Freenode and Discord. This is my first email to the Factory Mailing list so nice to e-meet you all :). I'd like to submit the package "menulibre" to you, which I already maintain on X11:xfce: "Menulibre" is a light but advanced application menu editor similar to "Alacarte" but more feature rich and independent from any Desktop Environment. It's a very good fit for light environments such as Xfce, with Whisker Menu already integrating it by default if installed. In addition Budgie, Cinnamon, GNOME, KDE (Plasma), LXDE, LXQt, MATE, Pantheon, Unity, are all supported. Menulibre is particularly useful for people who are not comfortable in editing config files to change menu entries, like for example new Linux users. Other distributions like Fedora, Mint and Xubuntu include this package as default for Xfce installations. It is actively maintained on Launchpad: https://launchpad.net/menulibre I've prepared a package on: /X11:xfce/menulibre I would very much appreciate feedbacks from anyone who may find it useful as I would really like to see this in Factory/Tumbleweed. Thank you all for your attention! Best Regards, Maurizio Galli Hong Kong -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

[opensuse-factory] Fwd: Bug? Re: problem with static linking. of util-linux utils meant to be statically linkable...

by L A Walsh

So I should file this as a bug against factory or tumbleweed? There was some disagreement about whether or not they should be treated the same? Because these utils 'should' be statically linkable and *are* on redhat (which I thought opensuse was based on). So how did static linking get broken for us but still work for redhat? -------- Original Message -------- Subject: problem with static linking. of util-linux utils meant to be statically linkable... Date: Sat, 06 Oct 2018 12:30:59 -0700 From: L A Walsh <suse(a)tlinx.org> To: SuSE Linux <opensuse(a)opensuse.org> Was trying the rc1 version of util-linux 2.33, and it has an option to link several of its utils statically. It works for the maintainer on redhat, and I was wondering why I'm having problems on opensuse... > $ ./configure --enable-static-programs=mount,umount > $ make mount.static umount.static ..... so I see... Except I got: CC sys-utils/mount_static-mount.o CCLD mount.static libtool: warning: complete static linking is impossible in this configuration /usr/bin/ld: total time in link: 0.038189 CC sys-utils/umount_static-umount.o CCLD umount.static libtool: warning: complete static linking is impossible in this configuration /usr/bin/ld: total time in link: 0.039017 with ldd: Ishtar:tools/util-linux/util-linux-2.33-rc1> ldd mount.static linux-vdso.so.1 (0x00007ffc38d78000) librt.so.1 => /lib64/librt.so.1 (0x0000003001c00000) libc.so.6 => /lib64/libc.so.6 (0x0000003000800000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003000c00000) /lib64/ld-linux-x86-64.so.2 (0x00007f81b9262000) So why would it work on redhat but not opensuse? Any ideas? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory October 2018