March 2015 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] acpid requires systemd?
by Felix Miata 25 Apr '24

25 Apr '24

Can this be true? If so, why? Zypper won't let me upgrade acpid without breakage unless systemd is installed too. I have systemd locked out, as I'd rather test things I can understand in Factory, not major overhaul stuff. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

4 3

[opensuse-factory] openSUSE maintainer finder tool
by Bernhard M. Wiedemann 14 Jan '16

14 Jan '16

Hi, during our Hackweek at SUSE I spent a day or two to improve my tool to help finding the maintainer for software in Factory, which comes in handy for bugzilla-screening (getting bugs to the right people). You can use the tool at http://maintainer.zq1.de/ You can give it command names, full filepath, or package names (exact matches (including case) only) If you want to run or extend it, the code is all open on https://github.com/bmwiedemann/susepkginfo and the databases can be fetched from http://aw.zq1.de/db.suse/ The actual maintainer information comes from OBS, so is always current. Ciao Bernhard M. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

11 14

[opensuse-factory] xgettext aborts [Fwd: Build failure of Base:System/coreutils-testsuite openSUSE_Factory/x86_64]
by Bernhard Voelker 30 Nov '15

30 Nov '15

What happened to xgettext? [ 198s] /usr/bin/xgettext --default-domain=coreutils --directory=.. \ [ 198s] --add-comments=TRANSLATORS: --keyword=_ --keyword=N_ --flag=_:1:pass-c-format --flag=N_:1:pass-c-format --flag=error:3:c-format --flag=error_at_line:5:c-format --flag=asnprintf:3:c-f ormat --flag=asprintf:2:c-format --flag=error:3:c-format --flag=error_at_line:5:c-format --flag=vasnprintf:3:c-format --flag=vasprintf:2:c-format --flag=verror:3:c-format --flag=verror_at_line:5:c- format --flag=wrapf:1:c-format --flag=xasprintf:1:c-format --flag=xfprintf:2:c-format --flag=xprintf:1:c-format --from-code=UTF-8 --keyword=proper_name:1,'"This is a proper name. See the gettext ma nual, section Names."' --keyword=proper_name_utf8:1,'"This is a proper name. See the gettext manual, section Names."' ${end_of_xgettext_options+} --flag=error:3:c-format --flag=error_at_line:5:c-f ormat --keyword='proper_name:1,"This is a proper name. See the gettext manual, section Names."' --keyword='proper_name_utf8:1,"This is a proper name. See the gettext manual, section Names."' --flag =asprintf:2:c-format --flag=vasprintf:2:c-format --flag=verror:3:c-format --flag=verror_at_line:5:c-format --flag=xprintf:1:c-format --flag=xvprintf:1:c-format --flag=xfprintf:2:c-format --flag=xvf printf:2:c-format --flag=xasprintf:1:c-format \ [ 198s] --files-from=./POTFILES.in \ [ 198s] --copyright-holder='Free Software Foundation, Inc.' \ [ 198s] --package-name="${package_gnu}coreutils" \ [ 198s] --package-version='8.22' \ [ 198s] --msgid-bugs-address="$msgid_bugs_address" \ [ 198s] ;; \ [ 198s] esac [ 198s] *** Error in `/usr/bin/xgettext': realloc(): invalid pointer: 0x00000000018ff590 *** [ 198s] ======= Backtrace: ========= [ 198s] /lib64/libc.so.6(+0x7343f)[0x7fa6640e043f] [ 198s] /lib64/libc.so.6(+0x78cae)[0x7fa6640e5cae] [ 198s] /lib64/libc.so.6(+0x7bde5)[0x7fa6640e8de5] [ 198s] /usr/lib64/libgettextlib-0.19.1.so(xrealloc+0xe)[0x7fa66445b56e] [ 198s] /usr/bin/xgettext[0x40b301] [ 198s] /usr/bin/xgettext[0x40b38d] [ 198s] /usr/bin/xgettext[0x40b4e1] [ 198s] /usr/bin/xgettext[0x40b98e] [ 198s] /usr/bin/xgettext[0x40ba93] [ 198s] /usr/bin/xgettext[0x40c340] [ 198s] /usr/bin/xgettext[0x406953] [ 198s] /usr/bin/xgettext[0x4052cc] [ 198s] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa66408eb05] [ 198s] /usr/bin/xgettext[0x405ba3] Have a nice day, Berny -------- Original Message -------- Subject: Build failure of Base:System/coreutils-testsuite openSUSE_Factory/x86_64 Date: Wed, 11 Jun 2014 18:15:31 +0000 From: hermes(a)opensuse.org Reply-To: hermes(a)opensuse.org To: mail(a)bernhard-voelker.de Package coreutils-testsuite (version 8.22-248.68) of project Base:System failed to build for openSUSE_Factory / x86_64. Review the build log: osc remotebuildlog Base:System coreutils-testsuite openSUSE_Factory x86_64 | less Check out the package for editing: osc checkout Base:System coreutils-testsuite -- Hermes messaging (http://hermes.opensuse.org) openSUSE Build Service (https://build.opensuse.org/) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 5

Re: [opensuse-factory] repository priorities with Tumbleweed
by Thomas Langkamp 16 Jul '15

16 Jul '15

> No, please don't confuse people, if you add more repos than just > Tumbleweed you really had better know what you are doing or bad things > can, and will, happen :) I understand. I just would like to add the following to http://en.opensuse.org/Portal:Tumbleweed - between ## is the new stuff: "The only supported method of repo use for Tumbleweed is to have only the main repos (Oss, Non-oss, and Update) and the Tumbleweed repo active. ## If you use more repositorys you have to know how repo-priorities work, but even then Tumblweed does NOT support this ## " It would also be good to move this information to "Special concerns" and to move the whole "Special concerns"-section up. For example "Special Concerns Virtual Machines ... Third Party Drivers ... ## Non-Standard Repos: Only use Oss, Non-oss, and Update combined with the Tumbleweed-Standard repo. Everything else is not supported and might break the system ## " >You do know the legal reasons behind why packman is there, right? Yes. Then I do not whish you personaly to support Packman with TW - I understand now that this is not possible from your perspectivg. But...as the OS community discusses right now if/how to strengthen Tumbleweed... one way would be, that Packman+TW would be supported BY Packman. So I will ask the Packman-guys to do that... I hope this is possible for them. Without Packman Tumbleweed is so ... "anti-multimedia" ;) thanks anyway :D -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

11 18

[opensuse-factory] openSUSE:Factory:NonFree repository
by Kyrill Detinov 03 Jul '15

03 Jul '15

Hello. /factory/repo/non-oss/ isn't updated since September 23. -- WBR Kyrill

4 9

[opensuse-factory] Action plans for Plasma 5 as default in openSUSE
by Luca Beltrame 19 May '15

19 May '15

(originally posted on opensuse-kde for initial discussion) Hello openSUSE KDE users and contributors, This mail outlines our plans for moving towards Plasma 5 as a default desktop for the next openSUSE release, includinga tentative action plan and where help from you all is required. We do not believe on pushing changes on users without some sort of preparation, therefore this document describes the transition plan. See the previous mails[0] for a rationale of this decision. [0] http://lists.opensuse.org/opensuse-kde/2015-03/msg00010.html ==== The plan ==== Phase 1: Gather input from the community In this phase, we would like people from the community, if they are able to, to test the currently-available code. It's quite easy, as all the required software is already available directly in Tumbleweed. You should install Plasma 5 from there (bear in mind that its install will not coexist with the 4.x workspace) and simply try using it. We are most interested with feedback, in particular: - Testing packaging - Testing upgrades of packages - Helping with building openQA tests - Checking for missing functionality Feedback will tracked through the following connect.opensuse.org polls: - Overall experience [1] : What does fowrk for you? What doesn't? - Missing functionality [2]: What are you missing from the 4.x workspace that you deem irrepleaceable? - Upgrade experience [3]: Was the upgrade from the 4.x packages smooth? Did anything break? - Visual and hardware-related issues [4]: Is Plasma 5 running well with your hardware? Bugs in the software should be reported upstream, but any issue in the packaging should be reported to openSUSE's Bugzilla. Phase 2: OpenQA testing We will discuss with the rest of the openSUSE community on how to handle Plasma 5 on openQA. This is where we need your help the most, because openQA needles are an important part of the openSUSE testing and we need many to ensure a smooth experience (and transition from 4.x), and we need a lot of them to ensure there are no hiccups down the road. Refer to http://os-autoinst.github.io/openQA/ to see how you can contribute. This phase will go as long as we can get comparable results as the 4.x workspace on openQA. === What about applications ? === As with regards to application releases from KDE (KDE Applications xx.yyy), our plan is to use directly what KDE releases, meaning that we will switch to KF5-based applications once upstream makes stable releases of them. If there are no KF5-based releases of a particular application, the currently available 4.x version will be used. === New repository layout === As part of the migration plan, when Plasma 5 becomes the default desktop in openSUSE the following changes will take place: - KDE:Frameworks5 (already the devel project for Plasma 5 and the KF5 libraries) will take the place of KDE:Distro:Factory (slowly phased out) - Application releases will be hosted in a separate development project, KDE:Applications KDE:Current, offering 4.x based releases, will be kept for users of past openSUSE versions. === Contingency plan === In case the issues reported during the testing period are too severe, we will revert back to the 4.x workspace and await further improvements from upstream. === How can I help ? === First and foremost: testing! We've been running the KF5 based desktop for a while but the team is small, we need more eyes looking for potential issues. Secondly: openQA tests are an essential foundation of an always-stable Tumbleweed, therefore this is another eare where help is warranted. A third area is documentation: wiki pages, guides, anything that can help in the transition. The team can help providing the required information. Above all: always be constructive when reporting issues. Saying "It sucks, get back to 4.x" is not only not going to help, but it is severely demotivating and that can be a problem with a task of this size. We're all humans, don't forget that. === Poll links === [1] https://connect.opensuse.org/pg/polls/read/luca_b/47114/what-is-your-experi… [2] https://connect.opensuse.org/pg/polls/read/luca_b/47132/what-functionality-… [3] https://connect.opensuse.org/pg/polls/read/luca_b/47168/how-was-your-upgrad… [4] https://connect.opensuse.org/pg/polls/read/luca_b/47184/how-is-your-plasma-… Luca Beltrame on behalf of the openSUSE community KDE Team -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

26 91

[opensuse-factory] Mandos in openSUSE
by mots 01 May '15

01 May '15

Hello, I was told on the opensuse(a)opensuse.org list to post this here. Debian GNU/Linux has a program called Mandos, which allows computers with encrypted root filesystem to boot unattended as long as they are in the same LAN segment as the mandos server. If someone steals the computer or copies the storage of an ecrypted VM then they'll still have to enter the password on boot. It needs to install its client in the initrd of the encrypted machine, which is why it only works on Debian GNU/Linux for now. I feel like it would be a great addition to openSUSE GNU/Linux, but it needs a lot of changes in the boot process in order to work. More info about Mandos: https://wiki.recompile.se/wiki/Mandos Regards, mots

2 1

[opensuse-factory] Apparmor fails to start on boot in Tumbleweed
by Uzair Shamim 17 Apr '15

17 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, After doing the latest updates for tumbleweed, I have noticed that it is failing to start on boot: linux-jyg:~ # systemctl status apparmor -l ● apparmor.service - LSB: AppArmor initialization Loaded: loaded (/etc/init.d/boot.apparmor) Active: inactive (dead) Docs: man:systemd-sysv-generator(8) Mar 29 12:22:46 linux-2jim systemd[1]: Job apparmor.service/start deleted to break ordering cycle starting with sysinit.target/start Mar 29 12:22:46 linux-2jim systemd[1]: Job apparmor.service/start deleted to break ordering cycle starting with basic.target/start Mar 29 12:22:46 linux-2jim systemd[1]: Job apparmor.service/start deleted to break ordering cycle starting with sysinit.target/start Mar 29 12:29:14 linux-jyg systemd[1]: Stopped LSB: AppArmor initialization. However, if I do systemctl start apparmor it will run fine. Is there some way I can determine what is causing apparmor to fail on boot? - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGCj6AAoJEM66EOTZRH6+UQMQALWH2nmFNyrIEGhFiDjSeGaD Pvnc/WdO0e2NyhluPf0SinEtC5YlEbNvBkniHSPEcYEBU0So6N8qbLvXxJ5146HF swvZAX4DaIlE70754DldA1Onz3AAaHZaCmFs3RijhaATGhOMm/8/zxezR1xlvu7N CO/fNF0vZs32j6Cewg7Z3AIcC1/c796PK0tUep7cbSjoctTH8QFwb3kI7NWAjGFF ezH1KsS5cOkClzN8eUOKfHAV6JyKrL9CK9XHYk4bYOZlpZ+ucQi1JV4JihtO8/N5 cP+QHA92nWskEtI2PBObCJmUaMW0BOYEzposZuxIJ+EBccjuDb0cXmHDVonirnqj 6JKI9n+LHoqI74PxczzqCa3ORShQfHdabBhi108ywYapJtfwV7YdWE8E0SuDvpav Y3oRfLFQzhICB7nh1VA07SReZYaXAlyf3lvG23ZvbX2PZqJ9qIKshJnoQ5WBzWwl DcDBvmPGWP7pbgdZenfTkbUWZfSaJ3otwzhsZrPEhA2eGMpMa0HgTLURwT2FBiv6 Z+sSmocZIHlxxWTxkC8Z9skU6VLoMvQRhSGZ+kFKk5yvQCoyC2I24q8yYC6+Wo52 6gRU33DqZBhjs/WDgMZzFKU4Y8LUIHBbQIb2kRQcDrCD+uIWSYSVnYrsyBstbL80 Re93XcxK2jyvQKkQEVpr =ab3o -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 32

[opensuse-factory] fstab, systemd and UUID
by Oliver Neukum 11 Apr '15

11 Apr '15

Hi, I recently experienced a filesystem issue that forced me to use the rescue system and I saw two issues regarding mounting filesystems that seemed bad to them 1) swap space is mounted by UUID That is problematic. If your swap space is corrupted you use mkswap. There practically is no other option. Doing so, however, you change the UUID and your system comes up without swap pretty much without warning. That is really nasty if you need to do S4 later on. It seems to me that swap should be mounted by device name. 2) systemd while coming up will tell you that a certain UUID is unavailable and fails to boot. That message is more less useless. You pretty much won't find the partition by UUID after you reboot into the rescue system because unless you have superhuman memory or take a photograph you will not have the UUID any more. And even if you had it, you won't find it for the same reason systemd failed to find it. A useful message would tell me where the filesystem was to be mounted at. Regards Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

17 52

[opensuse-factory] Upcoming transition to GCC 5
by Richard Biener 09 Apr '15

09 Apr '15

Hi, we are currently trying to get openSUSE:Factory:Rings:0-Bootstrap and openSUSE:Factory:Rings:1-MinimalX clean to build with GCC 5 in the openSUSE:Factory:Staging:Gcc49 project. Once that works reasonably I will push GCC 5 to Factory without enabling it as a default - that will be done when it works fully (help appreciated at that point). There is a porting-to document that explains some issues you may run into (also consider the 4.9 variant as we didn't transition to that): https://gcc.gnu.org/gcc-5/porting_to.html https://gcc.gnu.org/gcc-4.9/porting_to.html You may also find the analysis of Fedora interesting which explains why some packages now fail to build: https://lists.fedoraproject.org/pipermail/devel/2015-February/207549.html GCC 5 packages can be installed from devel:gcc where they are regularly updated. Those sources also feed openSUSE:Factory:Staging:Gcc49. Richard. -- Richard Biener <rguenther(a)suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

10 27