Hi all,
yesterday I startet to migrate my openSUSE machines from normal distribution to the
rolling-update Tumbleweed (currently openSUSE 12.3) - machines are productive and so Factory was no option.
After switching to Tumbleweed everything works fine except DRBD.
I found out that there is an inconsistency between drbd kernel module (V8.4.3 in kernel-default)
and the drbd admin tools (V8.3.11 from repository) which ends up with the inability to start the cluster volumes.
As workaround I found a matching rpm on suse build service, but please include a proper drbd-tools version in
the Tumbleweed repos.
Thx in advance.
Manfred
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hello guys,
in a few hours we will hopefully create 13.1 RC1 which will be announced with
all the fancy stuff Joss likes to do and I have no chance to fiddle with so I
would like to explain what you should do in order to get your changes into
13.1 from now on:
1) Always have bug number, yes now on your personal feeling that X fixes issue
Y does not matter, fill a bug and then refference it.
2) No version updates, just backport the patch if possible and go over Update
channel (few exceptions bellow)
3) When fixing things priority is over the installer/base as rest can be easily
handled via Update channel, so take look on P1+P2 and major/critical
importance bugs for Factory (and when 13.1 target is in bugzie check those)
and work on those at first.
Exceptions1) There still will be fixes merge backs for ie. arm/ppc because
these guys are still just making sure it builds and runs for them.
Exceptions2) If you notice we have devel branch of some software we thought we
will catch full release and it is not happening we should try to
downgrade/upgrade to provide stable-channel version.
So please reduce the SR# containing load of changes with comment "might be
good for 13.1" as it won't probably happen ;-) But you can always drop mail if
you really really think we should've picked up something right away to 13.1,
sometimes we overlook things.
Cheers
Tom
On Fre, 2013-09-27 at 21:53 -0700, Greg KH wrote:
>
>Ah, and it seems to be much more sane than md or lvm in that it is
>properly triggered off of udev rules, my mistake. Nice to see this.
>
>So, what should I do to fix Tumbleweed here? Any ideas?
>
>Update to latest version of udev? :)
The problem still persists after 2 weeks.
To explain the problem again:
80-btrfs.rules got removed in btrfsprogs, because it is already contained in
udev, but it is named 64-btrfs.rules there.
But the mkinitrd script in btrfsprogs still references 80-btrfs.rules.
That's why mkinitrd fails, if btrfsprogs is installed.
So I would suggest to revert btrfsprogs in Tumbleweed to this version for now,
which still contains 80-btrfs,rules :
https://build.opensuse.org/package/show/openSUSE:Tumbleweed/btrfsprogs?rev=9
Thank you.
Kindest Regards,
Wolfgang Bauer
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi,
I'd like to submit LevelDB as a new Factory development package.
As described on the project homepage[1], LevelDB is a fast key-value
storage library that provides an ordered mapping from string keys to
string values.
It is required by Ceph for key-value storage.
Cheers, David
1. http://code.google.com/p/leveldb/
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi,
increasingly recently I'm seeing constraints added to Factory packages
in this form:
<constraints>
<hardware>
<physicalmemory>
<size unit="M">2048</size>
</physicalmemory>
...
This tells OBS to not schedule the job on hosts that can not provide
at least 2048 Megabyte (2048 * 1024 * 1024 bytes). With other words,
this rules out all 32bit workers without LPAE extension.
Unfortunately due to unsolved upstream bugs, the current Guest kernel
we use for KVM builds does not have LPAE enabled, which means we can
boot VMs with 2000 MB memory maximum (actually a bit lower than that).
As a temporary measurement, I've hacked the workers to report 64GB of
memory to the scheduler so that those constraints are not effective,
but it would be nice to fix this at the source.
Please do not add a constraint that rules out any chance of 32bit ARM
builds unless you really really really need it (so far I have not seen
any package in Factory that cannot be made building with less than 2GB
of RAM though).
Thanks for reading!
Greetings,
Dirk
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
I generated a rather standard openSUSE 13.1 B1 system on my computer with one
Ethernet interface. So the I have a traditional ifup network configuration.
Nothing extra configured except some extra rules in SuSEfirewall2 to allow
DHCPV6 packages and mdns(5353). I have a modem which offers native IPv6
providing a prefix.
After booting it takes about 10 minutes after which the interface gets 2
global IPv6 addresses, the random one and the one derived from the MAC address
of the interface. The first one is used for outside connections.
If I do a ifdown and ifup on that interface, it takes less than one minute to
get the two global addresses.
After having the global addresses I do a ping6 to my router, in both cases
using the global address and link local address of the router, then I observe
packet loss. Most of the time the round trip delay is around 0.3 ms, however
on regular intervals I get exactly 1000 ms, but also packets are lost.
On my openSUSE 12.3 system on the same computer I use NetworkManager and I do
NOT see this behavior. Did not try it yet on 13.1.
Anyone seeing the same problem?
Bug report is: https://bugzilla.novell.com/show_bug.cgi?id=844683
--
fr.gr.
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Dear All,
I had the unpleasant surprise to find out that our lualatex is broken
when using fontspec (other packages may be involved too).
the offending document is
[alin@abaddon:~/lavello]: cat helloLua.tex
\documentclass[]{article}
\usepackage{fontspec}%
\begin{document}
Hello World!!
\end{document}
the output is
lualatex helloLua.tex
This is LuaTeX, Version beta-0.76.0-2013092812 (rev 4627)
restricted \write18 enabled.
(./helloLua.tex
LaTeX2e <2011/06/27>
Babel <3.9f> and hyphenation patterns for 78 languages loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))
(/home/alin/texmf/tex/latex/fontspec/fontspec.sty
(/usr/share/texmf/tex/latex/l3kernel/expl3.sty
(/usr/share/texmf/tex/latex/l3kernel/l3names.sty
(/usr/share/texmf/tex/latex/l3kernel/l3bootstrap.sty
(/usr/share/texmf/tex/generic/oberdiek/luatex.sty
(/usr/share/texmf/tex/generic/oberdiek/infwarerr.sty)
(/usr/share/texmf/tex/generic/oberdiek/ifluatex.sty)
(/usr/share/texmf/tex/latex/etex-pkg/etex.sty)
(/usr/share/texmf/tex/generic/oberdiek/luatex-loader.sty
(/usr/share/texmf/scripts/oberdiek/oberdiek.luatex.lua)))
(/usr/share/texmf/tex/generic/oberdiek/pdftexcmds.sty
(/usr/share/texmf/tex/generic/oberdiek/ltxcmds.sty)
(/usr/share/texmf/tex/generic/oberdiek/ifpdf.sty))))
(/usr/share/texmf/tex/latex/l3kernel/l3basics.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3expan.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3tl.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3seq.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3int.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3quark.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3prg.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3clist.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3token.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3prop.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3msg.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3file.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3skip.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3keys.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3fp.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3box.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3coffins.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3color.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3luatex.sty)
(/usr/share/texmf/tex/latex/l3kernel/l3candidates.sty))
(/usr/share/texmf/tex/latex/l3packages/xparse/xparse.sty)
(/usr/share/texmf/tex/luatex/luaotfload/luaotfload.sty
(/usr/share/texmf/tex/luatex/luatexbase/luatexbase.sty
(/usr/share/texmf/tex/luatex/luatexbase/luatexbase-compat.sty)
(/usr/share/texmf/tex/luatex/luatexbase/luatexbase-modutils.sty
(/usr/share/texmf/tex/luatex/luatexbase/luatexbase-loader.sty
(/usr/share/texmf/tex/luatex/luatexbase/luatexbase.loader.lua))
(/usr/share/texmf/tex/luatex/luatexbase/modutils.lua))
(/usr/share/texmf/tex/luatex/luatexbase/luatexbase-regs.sty)
(/usr/share/texmf/tex/luatex/luatexbase/luatexbase-attr.sty
(/usr/share/texmf/tex/luatex/luatexbase/attr.lua))
(/usr/share/texmf/tex/luatex/luatexbase/luatexbase-cctb.sty
(/usr/share/texmf/tex/luatex/luatexbase/cctb.lua))
(/usr/share/texmf/tex/luatex/luatexbase/luatexbase-mcb.sty
(/usr/share/texmf/tex/luatex/luatexbase/mcb.lua)))
(/usr/share/texmf/tex/luatex/luaotfload/luaotfload.lua)
(/usr/share/texmf/tex/luatex/luaotfload/luaotfload-merged.lua)
quiting: fix your writable cache path[alin@abaddon:~/lavello]:
can someone please confirm this before I report it as a bug?
regards,
Alin
--
Without Questions there are no Answers!
______________________________________________________________________
Dr. Alin Marin ELENA
http://alin.elenaworld.net/
______________________________________________________________________
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
I'm running apache 2.4 from Factory, and I've noticed an issue with
logrotate. It seems that apache does not reopen a logfile
when 'systemctl reload apache2' is issued.
My virtual hosts all have this:
CustomLog /srv/www/vhosts/vhost_access_log vhost
To rotate that log:
/srv/www/vhosts/vhost_access_log {
compress
dateext
maxage 365
rotate 30
daily
notifempty
missingok
create 644 root root
sharedscripts
postrotate
systemctl reload apache2
endscript
}
Has anyone else noticed this?
--
Per Jessen, Zürich (12.1°C)
http://www.hostsuisse.com/ - dedicated server rental in Switzerland.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Dear Listmates,
Maybe you have already noticed that the Chromium package was changed due to
the high number of rebuilds in the network:chromium project. The reason for
this is that I was able to simplify the build of chromium by using "official"
tarballs provided by the chromium developers. It seemed that openSUSE was the
only distro, that provided Chromium based on SVN snapshots and not utilizing
available tarballs.
In coordination with one of the Chromium developers (and chromium packager for
Gentoo), I successfully transferred our chromium build from the svn snapshot
to the released tarballs. As that the tarball does not deliver all the
required components, it took longer than expected to get the build the
openSUSE way. :-)
Based on the improved methodology, we are now able to build from the Chrome
stable, beta or even Dev channel. To increase usability, I will start
tracking the stable and beta channels:
+ The Beta channel will be used to update the packages in the network:chromium
repository, which also will be submitted to Factory
+ The Stable channel will be used to create maintenance updates for the
support openSUSE versions (if possible due to requirements on certain package
versions) and these maintenance updates will be build in the
network:chromium:stable project.
The current Beta (31.0.1650.8) was build in network:chromium and was just
submitted to Factory
The current stable (30.0.1599.69) will be build in network:chromium:stable as
soon as the tarball is available and then submitted to openSUSE_12.3 as
maintenance update. Unfortunately this is not possible for openSUSE 12.2 as
that it requires a higher version of nspr/nss than available on 12.2.
Regards
Raymond
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi
13.1 beta 1
When trying to get Kerberos tickets, the directory does not exist e.g.
as root:
kinit Administrator
kinit: Credential cache directory /run/user/0/krb5cc does not exist
while getting default ccache
If I now create the directory:
/run/user/0
and now kinit, it works fine and I get a ticket.
This is different behavior from 12.3, where the ticket cache was stored
in /tmp
Can I:
1. Get back to the 12.3 behaviour?
2. Adjust something to create the /run/user/0 directory if root attempts
a kinit?
Thanks,
Lynn
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org