Re: prefered way of configuring X11 keyboard layouts in F18

2012-12-24 Thread Lennart Poettering
On Fri, 21.12.12 16:11, Adam Williamson (awill...@redhat.com) wrote:

 On Fri, 2012-12-21 at 16:57 +0100, Lennart Poettering wrote:
 
   The database is bitrotten and even it it wasn't most modern layouts do not
   exist kbd-side at all. Most layouts with perfect mapping are old legacy
   ascii layouts. They are still in xkb-config for historical reasons but in
   many locales the preferred layout includes changes (unicode…) which have
   never been ported to kbd.
  
  I doubt it's that rotten. It definitely works fine for the most popular
  keymaps, such as the american and german. 
 
 All this keymap stuff is bending my brain, but I've been poking at it
 for the last few days, and I'm rather afraid it *is* that bad. See this
 tentatively accepted blocker bug:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=889562
 
 If I have everything right, anaconda is offering a keymap list that it
 derives from xkb. I'm having trouble counting precisely how many layouts
 it offers, but it looks to be definitely over 400.
 
 According to 'localectl list-keymaps', systemd-localed has mappings for
 209 keymaps.

Well, that's simply a fact that the console keymaps are much fewer than
the X keymaps, but that's not really an issue of localed/systemd, but
rather a general shortcoming of the classic console keymap system. Also,
it's hardly a regression in comparison to older Fedora...

 So there's at least 191 keymaps (probably rather more) which anaconda
 offers you but which systemd doesn't understand: if you install with any
 of these keymaps selected as the default keymap (top of the list in
 Keyboard spoke), you will wind up with US as your console keyboard
 layout on the installed system.
 
 We could really do with input from interested parties on exactly how bad
 of a problem this is - if people could look through the keyboard layouts
 offered in F18's Keyboard spoke and compare them to the list from
 'localectl list-keymaps', and identify particularly important ones that
 systemd doesn't seem to grok, it'd really help.

localectl list-keymaps shows all files below /usr/lib/kbd/keymaps btw,
that's all it does...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fosdem Cross-Distro devroom

2012-12-24 Thread Nikos Roussos

Just an update about Fosdem.

The dealing for talk submissions at the Cross Distro Devroom got 
extended until the end of the year [1].


I have already submitted a talk [2], but I think it's the only Fedora 
related. So anyone interested on doing a presentation, now it's the time 
to propose it :)



[1] 
https://lists.fosdem.org/pipermail/distributions/2012-December/000169.html
[2] 
https://lists.fosdem.org/pipermail/distributions/2012-December/000160.html

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20121224 changes

2012-12-24 Thread Fedora Rawhide Report
Compose started at Mon Dec 24 08:15:09 UTC 2012

Broken deps for x86_64
--
[Agda]
Agda-2.3.0.1-4.fc19.x86_64 requires 
ghc(Agda-2.3.0.1-ad754944fc95f11aa3b4710387ff959a)
[airinv]
airinv-0.1.2-5.fc19.i686 requires libstdairuicl.so.0.45
airinv-0.1.2-5.fc19.i686 requires libstdair.so.0.45
airinv-0.1.2-5.fc19.x86_64 requires libstdairuicl.so.0.45()(64bit)
airinv-0.1.2-5.fc19.x86_64 requires libstdair.so.0.45()(64bit)
[airrac]
airrac-0.2.3-5.fc19.i686 requires libstdairuicl.so.0.45
airrac-0.2.3-5.fc19.i686 requires libstdair.so.0.45
airrac-0.2.3-5.fc19.x86_64 requires libstdairuicl.so.0.45()(64bit)
airrac-0.2.3-5.fc19.x86_64 requires libstdair.so.0.45()(64bit)
[airsched]
airsched-0.1.4-5.fc19.i686 requires libstdairuicl.so.0.45
airsched-0.1.4-5.fc19.i686 requires libstdair.so.0.45
airsched-0.1.4-5.fc19.x86_64 requires libstdairuicl.so.0.45()(64bit)
airsched-0.1.4-5.fc19.x86_64 requires libstdair.so.0.45()(64bit)
[almanah]
almanah-0.10.0-3.fc19.x86_64 requires libedataserverui-3.0.so.5()(64bit)
almanah-0.10.0-3.fc19.x86_64 requires libcamel-1.2.so.42()(64bit)
[ansible]
ansible-fireball-0.9-1.fc19.noarch requires python-keyczar
ansible-node-fireball-0.9-1.fc19.noarch requires python-keyczar
[cp2k]
cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpichf90.so.3()(64bit)
cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpich.so.3()(64bit)
[dogtag-pki]
dogtag-pki-10.0.0-0.16.b3.fc19.noarch requires dogtag-pki-server-theme 
= 0:10.0.0
[dvdauthor]
dvdauthor-0.7.1-1.fc18.x86_64 requires libGraphicsMagick.so.3()(64bit)
[ekiga]
ekiga-4.0.0-1.fc19.x86_64 requires libcamel-1.2.so.42()(64bit)
[ember]
ember-0.6.3-3.fc19.x86_64 requires libOgreMain.so.1.7.4()(64bit)
[epiphany-extensions]
epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6
[evolution-rss]
1:evolution-rss-0.3.92-3.fc19.x86_64 requires 
libevolution-utils.so()(64bit)
1:evolution-rss-0.3.92-3.fc19.x86_64 requires 
libemiscwidgets.so()(64bit)
1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemail-utils.so()(64bit)
1:evolution-rss-0.3.92-3.fc19.x86_64 requires 
libedataserverui-3.0.so.5()(64bit)
1:evolution-rss-0.3.92-3.fc19.x86_64 requires 
libcamel-1.2.so.42()(64bit)
[freeipa]
freeipa-server-3.1.0-1.fc19.x86_64 requires dogtag-pki-server-theme
[freewrl]
freewrl-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7
freewrl-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit)
libEAI-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7
libEAI-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
[ghc-wai-extra]
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSzlib-conduit-0.4.0.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSzlib-bindings-0.1.0.1-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSzlib-0.5.3.3-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSwai-1.2.0.3-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSvoid-0.5.6-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSvault-0.2.0.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSunordered-containers-0.2.1.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSunix-2.5.1.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHStransformers-base-0.4.1-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHStransformers-0.3.0.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHStime-1.4-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHStext-0.11.2.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSresourcet-0.3.2.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSparsec-3.1.2-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSold-time-1.1.0.0-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSold-locale-1.0.0.4-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSnetwork-2.3.0.13-ghc7.4.1.so()(64bit)
ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires 
libHSmtl-2.1.1-ghc7.4.1.so()(64bit)
 

F-18 Branched report: 20121224 changes

2012-12-24 Thread Fedora Branched Report
Compose started at Mon Dec 24 09:17:00 UTC 2012








Summary:
Added Packages: 0
Removed Packages: 0
Upgraded Packages: 0
Compose finished at Mon Dec 24 13:18:15 UTC 2012

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes for today's FESCo meeting (2012-12-19)

2012-12-24 Thread Kevin Kofler
Matthew Garrett wrote:
 Unit files need to be in /, so moving them would either require creating
 a /share for distributions that haven't merged /usr or putting up with
 inconsistent naming between distributions. Consistency is a virtue and
 the chances of getting anyone else to accept /share are minimal, so /lib
 it is. Meanwhile, libexec's not part of any non-draft version of the FHS
 and doesn't exist on most other distributions, and the path of the
 helper binaries has ended up in a bunch of unit files. So, similar
 problems.
 
 What benefit do you see in modifying systemd?

Consistency WITHIN FEDORA, which should be worlds more important than 
consistency with other distros, which frankly I don't give a darn about.

As for libexec, the FHS explicitly allows lib* under the multilib clause and 
there's nothing banning * = exec there, so IMHO libexec is already compliant 
to the letter of the FHS. If the other distros refuse to accept that, that's 
their problem. Systemd should just require it upstream. libexec is also part 
of the GNU file system conventions, so it wouldn't just be systemd. If 
systemd upstream refuses to do that, the systemd maintainers should be 
forced to change it in Fedora.

And a /share also makes a lot of sense for distros which have a separate 
/usr. There too, systemd should just require it upstream, but again, if they 
refuse to do that, they should be forced to change it in Fedora.

Being strict there might actually end up getting our sane layout enforced 
through systemd upstream, rather than having it diluted in the name of 
consistency with other distros. And if it doesn't, it's too bad for the 
other distros, why should we care?

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes for today's FESCo meeting (2012-12-19)

2012-12-24 Thread Kevin Kofler
Miloslav Trmač wrote:
 The exceptions were granted to avoid the impact of fixing this on
 developers, and more importantly on users (the /usr/lib/systemd paths
 for units are in various documentation, and even worse the paths to
 binaries in /usr/lib/systemd are embedded in users' copies of units
 placed in /etc/; moving the binaries would break users'
 configuration).

Guess what, the documentation needs to be updated.

Systemd as is does not conform to any sane file system structure. This MUST 
be fixed, even if it means breaking compatibility.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

system-config-firewall conntrack patch

2012-12-24 Thread Andrew Wyatt
Howdy folks, saw that you hadn't patched system-config-firewall to 
support conntrack so I thought I'd send our patch your way.  Not a large 
contribution by any means, but I hope it helps.


diff -rupN system-config-firewall-1.2.29.orig/src/fw_iptables.py 
system-config-firewall-1.2.29/src/fw_iptables.py
--- system-config-firewall-1.2.29.orig/src/fw_iptables.py 2012-12-24 
14:44:23.094496819 -0500
+++ system-config-firewall-1.2.29/src/fw_iptables.py2012-12-24 
14:46:06.040498696 -0500

@@ -362,7 +362,7 @@ class iptablesClass:

 # accept established and related connections as early as possible
 #   RELATED is extremely important as it matches ICMP error 
messages
-fd.write(-A INPUT -m state --state ESTABLISHED,RELATED -j 
ACCEPT\n)
+fd.write(-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED 
-j ACCEPT\n)


 # icmp
 self._icmp(conf, fd, INPUT, reject_type)
@@ -377,7 +377,7 @@ class iptablesClass:
 for fwd in conf.forward_port:
 if fwd.has_key(toaddr):
 continue
-line = -A INPUT -i %s -m state --state NEW -m %s -p 
%s % \
+line = -A INPUT -i %s -m conntrack --ctstate NEW -m %s 
-p %s % \

 (fwd[if], fwd[proto], fwd[proto])
 if fwd.has_key(toport):
 line +=  --dport %s % self._portStr(fwd[toport])
@@ -394,7 +394,7 @@ class iptablesClass:
 _dest = 
 _port = 
 if proto in [ tcp, udp ]:
-_state = -m state --state NEW 
+_state = -m conntrack --ctstate NEW 
 _proto = -m %s -p %s  % (proto, proto)
 else:
 if self.type == ipv4:
@@ -411,7 +411,7 @@ class iptablesClass:
 # open ports
 if conf.ports and len(conf.ports)  0:
 for (ports, proto) in conf.ports:
-fd.write(-A INPUT -m state --state NEW -m %s -p %s 
--dport %s 
+fd.write(-A INPUT -m conntrack --ctstate NEW -m %s -p 
%s --dport %s 
  -j ACCEPT\n % (proto, proto, 
self._portStr(ports)))


 # FORWARD
@@ -419,7 +419,7 @@ class iptablesClass:
 (self.type == ipv4 and conf.masq and len(conf.masq) 
 0) or \

 (self.type == ipv4 and remote_forward):
 # accept established and related connections
-fd.write(-A FORWARD -m state --state ESTABLISHED,RELATED 
+fd.write(-A FORWARD -m conntrack --ctstate 
ESTABLISHED,RELATED 

  -j ACCEPT\n)
 # icmp
 self._icmp(conf, fd, FORWARD, reject_type)
@@ -442,7 +442,7 @@ class iptablesClass:
 port = self._portStr(fwd[toport])
 else:
 port = self._portStr(fwd[port])
-fd.write(-A FORWARD -i %s -m state --state NEW 
+fd.write(-A FORWARD -i %s -m conntrack --ctstate NEW 
  -m %s -p %s -d %s --dport %s 
  -j ACCEPT\n % (fwd[if], fwd[proto],
   fwd[proto], fwd[toaddr],

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel