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
> 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
(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
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
-----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
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
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.htmlhttps://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
Hello.
Recently updated my Factory running workstation (x86_64, Xfce).
Monospace font interval is increased badly.
I'm sure, I use DejaVu Sans Mono as a monospace font.
I choose 'monospace 9' in programs settings.
There is a screenshot: http://susepaste.org/view/simple/38919191
Changing to 'DejaVu Sans Mono 9':
http://susepaste.org/view/simple/70371539
It looks like it was before.
% fc-match Monospace
Fontconfig warning: "/etc/fonts/conf.d/56-user.conf", line 14: reading
configurations from ~/.fonts.conf is deprecated. please move it
to /home/kent/.config/fontconfig/fonts.conf manually Monospace:
"Monospace" "Regular"
--
WBR
Kyrill