Re: trouble submitting fc26 package to bodhi

[Pádraig Brady]

On 05/04/17 21:14, Adam Williamson wrote:
> On Wed, 2017-04-05 at 21:03 -0700, Pádraig Brady wrote:
>> Hi,
>>
>> It looks like bodhi is open to fc26 updates,
>> though I don't seem to be able to create them
>> for packages I built a few weeks ago?
>>
>> $ fedpkg update ...
>> Creating a new update for  crudini-0.9-1.fc26
>> fedora.client.bodhi.BodhiClientException:
>> Unable to determine release from build: crudini-0.9-1.fc26
>>
>> Note that was after I did the following
>> (which did seem to allow me to progress further):
>> $ koji tag-build f26-updates-candidate crudini-0.9-1.fc26
> 
> You built it before the Bodhi activation point, so it doesn't need to
> go through Bodhi. It's already in F26. Note it has the 'f26' tag.
> 

Indeed. I see this now with:
koji buildinfo crudini-0.9-1.fc26

thanks!
Pádraig
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

trouble submitting fc26 package to bodhi

[Pádraig Brady]

Hi,

It looks like bodhi is open to fc26 updates,
though I don't seem to be able to create them
for packages I built a few weeks ago?

$ fedpkg update ...
Creating a new update for  crudini-0.9-1.fc26
fedora.client.bodhi.BodhiClientException:
Unable to determine release from build: crudini-0.9-1.fc26

Note that was after I did the following
(which did seem to allow me to progress further):
$ koji tag-build f26-updates-candidate crudini-0.9-1.fc26

cheers,
Pádraig
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Koji builders' specs

[Pádraig Brady]

On 22/12/16 13:13, Pádraig Brady wrote:
> On 21/12/16 16:04, Dan Horák wrote:
>> On Tue, 20 Dec 2016 16:03:49 +0100
>> Pavel Raiskup  wrote:
>>
>>> Hi all,
>>>
>>> where is documented what system/hw is used on (primary) Koji builders?
>>> I'm interested in memory, storage, filesystem, host operating system,
>>> guest operating system (if those are VMs), etc.
>>>
>>> The only thing I was able to find is version of mock in the log
>>> output.
>>>
>>> FWIW, I'd like to reproduce hang in gnulib's test-lock [1] test case.
>>> Unless I'm able to reproduce that somehow, I'll disable the test for
>>> the time being (done in 'coreutils' and I guess elsewhere, too).
>>
>> oh no, test-lock again :-( A year (or two) ago it turned to be a kernel
>> bug - https://bugzilla.redhat.com/show_bug.cgi?id=1155291
> 
> I saw Kamil recently disabled that test for the coreutils update.
> Note the test itself may have issues as discussed at:
> https://lists.gnu.org/archive/html/bug-gnulib/2015-07/msg00032.html

Note this test was just changed upstream to use locks instead of volatiles,
which significantly improved performance on a 40 core NUMA system at least:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=480d374

cheers,
Pádraig
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Koji builders' specs

[Pádraig Brady]

On 21/12/16 16:04, Dan Horák wrote:
> On Tue, 20 Dec 2016 16:03:49 +0100
> Pavel Raiskup  wrote:
> 
>> Hi all,
>>
>> where is documented what system/hw is used on (primary) Koji builders?
>> I'm interested in memory, storage, filesystem, host operating system,
>> guest operating system (if those are VMs), etc.
>>
>> The only thing I was able to find is version of mock in the log
>> output.
>>
>> FWIW, I'd like to reproduce hang in gnulib's test-lock [1] test case.
>> Unless I'm able to reproduce that somehow, I'll disable the test for
>> the time being (done in 'coreutils' and I guess elsewhere, too).
> 
> oh no, test-lock again :-( A year (or two) ago it turned to be a kernel
> bug - https://bugzilla.redhat.com/show_bug.cgi?id=1155291

I saw Kamil recently disabled that test for the coreutils update.
Note the test itself may have issues as discussed at:
https://lists.gnu.org/archive/html/bug-gnulib/2015-07/msg00032.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New sources format

[Pádraig Brady]

On 20/12/16 22:28, Christopher wrote:
> What's with the new sources format?
> The old format, I could do `md5sum -c sources`
> Why not make the new format with SHA512 follow the same pattern, so I could 
> do: `shasum -c sources` or `sha512sum -c sources`?
> 
> Is there any standard command-line tool to parse this new format, or do I 
> just gotta grep/awk/bash my way through it?

As far as I can see it's using the BSD tagged format,
which the coreutils sha512sum command can parse.
I.E. the following format is supported since v8.20 (2012-10-23)

  SHA512 (filename) = ...

cheers,
Pádraig
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: The 'rpm -q --whatrequires' variant to get list of all dependant packages?

[Pádraig Brady]

On 10/11/16 07:08, Pavel Raiskup wrote:
> Is there something similar to 'dnf repoquery --whatrequires foo-libs 
> --all-deps'
> in RPM?  See the following:
> 
> $ rpm -q --whatrequires libarchive
> no package requires libarchive
> $ sudo dnf remove libarchive
> Dependencies resolved.
> Error: The operation would result in removing the following protected 
> packages: dnf.

You can do that with `rpm -e --test`.
I've a wrapper script for deb and rpm at:
http://www.pixelbeat.org/scripts/whatrequires
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Slow configure scripts

[Pádraig Brady]

On 27/10/16 20:19, Pádraig Brady wrote:
> On 27/10/16 17:09, Pavel Raiskup wrote:
>> On Thursday, October 27, 2016 3:23:25 PM CEST Pádraig Brady wrote:
>>> On 24/10/16 17:35, Florian Weimer wrote:
>>>> I recall some reports that configure scripts are really slow in recent 
>>>> Fedora versions due to pervasive use of BIND_NOW.
>>>>
>>>> Has anyone investigated this further?  Is there a bug report somewhere?
>>>
>>> Related to this I was wondering if there was any thought
>>> to providing distro wide config.cache file that was primed with
>>> results from base system libs and enabled with the rpm %{configure} macro?
>>
>> What set of defaults would be in system-wide config.cache file?  Would you
>> generate config.cache only for "minimal" buildroot?
> 
> That would work. Even one generated per glibc build would suffice.
> Priming per minimal buildroot it would help Fedora,
> though it might also be useful to distribute the cache for users.

This might also be achieved through the site defaults mechanism:
https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Site-Defaults.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Slow configure scripts

[Pádraig Brady]

On 27/10/16 17:09, Pavel Raiskup wrote:
> On Thursday, October 27, 2016 3:23:25 PM CEST Pádraig Brady wrote:
>> On 24/10/16 17:35, Florian Weimer wrote:
>>> I recall some reports that configure scripts are really slow in recent 
>>> Fedora versions due to pervasive use of BIND_NOW.
>>>
>>> Has anyone investigated this further?  Is there a bug report somewhere?
>>
>> Related to this I was wondering if there was any thought
>> to providing distro wide config.cache file that was primed with
>> results from base system libs and enabled with the rpm %{configure} macro?
> 
> What set of defaults would be in system-wide config.cache file?  Would you
> generate config.cache only for "minimal" buildroot?

That would work. Even one generated per glibc build would suffice.
Priming per minimal buildroot it would help Fedora,
though it might also be useful to distribute the cache for users.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Slow configure scripts

[Pádraig Brady]

On 24/10/16 17:35, Florian Weimer wrote:
> I recall some reports that configure scripts are really slow in recent 
> Fedora versions due to pervasive use of BIND_NOW.
> 
> Has anyone investigated this further?  Is there a bug report somewhere?

Related to this I was wondering if there was any thought
to providing distro wide config.cache file that was primed with
results from base system libs and enabled with the rpm %{configure} macro?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Minimizing the fedora docker base image footprint

[Pádraig Brady]

On 22/02/16 06:54, Courtney Pacheco wrote:
> Hi everyone,
> 
> I've spent some time trying to minimize the footprint of the Fedora 
> docker base image. Overall, I managed to reduce its size by 39.9%.

Excellent.

You might want to keep in mind the use of "coreutils-single"
for Fedora 24 (or backport that packaging change to F23).
It reduces coreutils from about 15MB to 1MB.

cheers,
Pádraig.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Pádraig Brady]

On 01/12/15 15:59, Randy Barlow wrote:
> This sounds overall pretty neat to me! One detail came to my mind: how
> would this interact with VPN DNS servers? In my experience with VPNs,
> it's common for them to provide a DNS server that allows internal host
> resolution to work. Would this local resolver be notified by NM of a new
> VPN connection so that it knows to use the VPN-provided DNS server for
> hosts on that particular domain, rather than the usual external records
> for that same domain?

That split DNS setup has been working well for me since Fedora 21,
which I enabled using:

  dnf install crudini
  crudini --set /etc/NetworkManager/conf.d/99-split-dns.conf main dns dnsmasq

Details of that setting are in man NetworkManager.conf
Not sending general DNS queries over the VPN
improves speed and avoids stalls when the VPN drops.

cheers,
Pádraig
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: building conflicting packages from a single spec

[Pádraig Brady]

On 19/11/15 11:11, Florian Festi wrote:
> On 11/18/2015 04:26 AM, Pádraig Brady wrote:
>> Is $subject possible?
>>
>> For example generating subpackages like:
>>   %{name}-small-but-slow-binaries
>>   %{name}-fast-but-big-binaries
>>
>> I can %prep and %install into separate areas,
>> though was then wondering how to adjust
>> the buildroot for subpackages?
>>
>> Are any other techniques possible?
>> I suppose I could manually set conflicts,
>> and then move binaries post install,
>> though what happens if mv is one of the
>> binaries for example?
>>
>> cheers,
>> Pádraig.
>>
> 
> I added RemovePathPostfixes in 4.13. But is still kinda lacks proper
> documentation. See
> http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=415aa42566052db9b7677163cea0366e55f72dcf
> 
> It is also more useful for things like different config files than
> different builds...

Oh that works well in my case!
I installed the multicall stubs to $bin.single
and 'RemovePathPostfixes: .single' removes those suffixes later.
The advantage of that is that rpm handles the file provides appropriately.

thanks!
Pádraig.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: building conflicting packages from a single spec

[Pádraig Brady]

On 18/11/15 22:34, Richard W.M. Jones wrote:
> On Wed, Nov 18, 2015 at 04:34:16PM +0000, Pádraig Brady wrote:
>> On 18/11/15 03:31, Jason L Tibbitts III wrote:
>>>>>>>> "PB" == Pádraig Brady  writes:
>>>
>>> PB> Is $subject possible?
>>>
>>> I don't think so, since at the end of %install you have exactly one set
>>> of files in one buildroot.
>>
>> Right. There was talk of potential support for this ages ago:
>> https://www.redhat.com/archives/rpm-list/2002-July/msg00222.html
>>
>>> Still, I don't see a reason for the
>>> subpackages to actually conflict.
>>>
>>> PB> Are any other techniques possible?
>>>
>>> Install the binaries under separate names and use simple scripts to
>>> decide which to run (or use alternatives, but ugh.)  Install libraries
>>> into separate paths and use the scripts to set the library path.
>>>
>>> If the software uses dlopen, just fix it to open the proper library
>>> based on the capabilities of the machine.
>>
>> Yes not ideal.
>> What I've done in %post is to mv the conflicting files
>> from a temp to standard location, overwriting any existing files.
> 
> That's horrible for supermin to deal with.  Can I ask at least that
> the non-single-file coreutils version (ie. the normal one) isn't the
> one which uses the %post script?

I didn't mention coreutils in this thread.
You don't miss much :)

Yes this is related to the coreutils split I was looking at.
I've come up with something fairly clean.
The normal coreutils package is unchanged.
coreutils-single is also now a "normal package" which will
not modify any installed files and thus verify correctly after install.
I was able to add new links in the %post stage to the packaged files,
leveraging the multicall binary handling.  It works well in a chroot at least.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Some analysis on the size of the minimal and Server installs of Fedora 23

[Pádraig Brady]

On 17/11/15 17:03, Pádraig Brady wrote:
> On 17/11/15 01:39, Stephen Gallagher wrote:
>> (Please keep responses on the devel@ list; I've set it in the Reply-To.)
>>
>> To jump right to the premise: The default Fedora Server install is Way
>> Too Big(TM) and the minimal install (also available on the Fedora
>> Server install media) is also Too Big.

>> Some highlights of my initial research (with a lot of my raw data in
>> the tarball attached to this email):
>>
>>
>> == Minimal ==
>>
>> === Disk Usage ===
>> /boot: 79MB
>> /: 755MB
>>
>>
>> === Packages ===
>> Total count: 270
>>
>>  Largest 10 packages 
>> 14288083: coreutils
> 
> We might create a coreutils-singlebin package that is built with
>   ./configure --enable-single-binary
> which would include only the single binary and stubs.
> I think chromium is using this setup.
> coreutils-singlebin could Recommends: coreutils-doc, while the
> standard coreutils package would require coreutils-doc.
> That would save about 13MB in the install.
> Caveat is that the single binary would dynamically link
> all shared libs, which associated startup and mem overhead.

Attached is a proposed split for coreutils.

Original coreutils (14.2MB) is now split to:

coreutils (5.5MB), coreutils-single (1.2MB)
and an optional coreutils-common (8.7MB)

coreutils and coreutils-single are mutually exclusive.
coreutils requires coreutils-common, though it
can be forcefully removed if desired, and only
docs and translations are degraded.

I.E. there are 4 possible setups now:

coreutils-single (1.2MB)
coreutils-single + coreutils-common (9.9MB)
coreutils (5.5MB)
coreutils + coreutils-common (14.2MB)

cheers,
Pádraig.
From 3b01b048617cc689fa7a92aba9a153838719dc68 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Tue, 17 Nov 2015 23:58:22 +
Subject: [PATCH 1/2] clean stale parts of the spec file

---
 coreutils.spec | 122 -
 1 file changed, 8 insertions(+), 114 deletions(-)

diff --git a/coreutils.spec b/coreutils.spec
index 20cdfe6..4ec62d5 100644
--- a/coreutils.spec
+++ b/coreutils.spec
@@ -152,7 +152,7 @@ the old GNU fileutils, sh-utils, and textutils packages.
 %patch950 -p1 -b .selinux
 %patch951 -p1 -b .selinuxman
 
-chmod a+x tests/misc/sort-mb-tests.sh tests/df/direct.sh tests/cp/no-ctx.sh || :
+chmod a+x tests/misc/sort-mb-tests.sh tests/df/direct.sh || :
 
 #fix typos/mistakes in localized documentation(#439410, #440056)
 find ./po/ -name "*.p*" | xargs \
@@ -167,29 +167,20 @@ touch aclocal.m4 configure config.hin Makefile.in */Makefile.in
 aclocal -I m4
 autoconf --force
 automake --copy --add-missing
-%configure --enable-largefile \
+%configure --enable-install-program=arch \
+   --enable-no-install-program=uptime \
--with-openssl \
-   --enable-install-program=hostname,arch \
--with-tty-group \
DEFAULT_POSIX2_VERSION=200112 alternative=199209 || :
 
-# Regenerate manpages
-touch man/*.x
-
 make all %{?_smp_mflags}
 
-# XXX docs should say /var/run/[uw]tmp not /etc/[uw]tmp
-sed -i -e 's,/etc/utmp,/var/run/utmp,g;s,/etc/wtmp,/var/run/wtmp,g' doc/coreutils.texi
-
 %check
 make check %{?_smp_mflags}
 
 %install
 make DESTDIR=$RPM_BUILD_ROOT install
 
-# man pages are not installed with make install
-make mandir=$RPM_BUILD_ROOT%{_mandir} install-man
-
 # fix japanese catalog file
 if [ -d $RPM_BUILD_ROOT%{_datadir}/locale/ja_JP.EUC/LC_MESSAGES ]; then
mkdir -p $RPM_BUILD_ROOT%{_datadir}/locale/ja/LC_MESSAGES
@@ -214,7 +205,10 @@ install -p -c -m644 %SOURCE105 $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/colorls.s
 install -p -c -m644 %SOURCE106 $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/colorls.csh
 
 # These come from util-linux and/or procps.
-for i in hostname uptime kill ; do
+# With coreutils > 8.24 one can just add to --enable-no-install-program
+# rather than manually removing here, since tests depending on
+# built utilities are correctly skipped if not present.
+for i in kill ; do
 rm $RPM_BUILD_ROOT{%{_bindir}/$i,%{_mandir}/man1/$i.1}
 done
 
@@ -269,107 +263,7 @@ fi
 %doc ABOUT-NLS NEWS README THANKS TODO
 %{!?_licensedir:%global license %%doc}
 %license COPYING
-%{_bindir}/arch
-%{_bindir}/basename
-%{_bindir}/cat
-%{_bindir}/chgrp
-%{_bindir}/chmod
-%{_bindir}/chown
-%{_bindir}/cp
-%{_bindir}/cut
-%{_bindir}/date
-%{_bindir}/dd
-%{_bindir}/df
-%{_bindir}/echo
-%{_bindir}/env
-%{_bindir}/false
-%{_bindir}/link
-%{_bindir}/ln
-%{_bindir}/ls
-%{_bindir}/mkdir
-%{_bindir}/mknod
-%{_bindir}/mv
-%{_bindir}/nice
-%{_bindir}/pwd
-%{_bindir}/readlink
-%{_bindir}/rm
-%{_bindir}/rmdir
-%{_bindir}/sleep
-%{_bindir}/sort
-%{_bindir}/stty
-%{_bindir}/sync
-%{_bindir}/mktemp
-%{_bindir}/touch
-%{_bindir}/true
-%{_bindir}/uname
-%{_bindi

Re: building conflicting packages from a single spec

[Pádraig Brady]

On 18/11/15 03:31, Jason L Tibbitts III wrote:
>>>>>> "PB" == Pádraig Brady  writes:
> 
> PB> Is $subject possible?
> 
> I don't think so, since at the end of %install you have exactly one set
> of files in one buildroot.

Right. There was talk of potential support for this ages ago:
https://www.redhat.com/archives/rpm-list/2002-July/msg00222.html

> Still, I don't see a reason for the
> subpackages to actually conflict.
> 
> PB> Are any other techniques possible?
> 
> Install the binaries under separate names and use simple scripts to
> decide which to run (or use alternatives, but ugh.)  Install libraries
> into separate paths and use the scripts to set the library path.
> 
> If the software uses dlopen, just fix it to open the proper library
> based on the capabilities of the machine.

Yes not ideal.
What I've done in %post is to mv the conflicting files
from a temp to standard location, overwriting any existing files.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

building conflicting packages from a single spec

[Pádraig Brady]

Is $subject possible?

For example generating subpackages like:
  %{name}-small-but-slow-binaries
  %{name}-fast-but-big-binaries

I can %prep and %install into separate areas,
though was then wondering how to adjust
the buildroot for subpackages?

Are any other techniques possible?
I suppose I could manually set conflicts,
and then move binaries post install,
though what happens if mv is one of the
binaries for example?

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Some analysis on the size of the minimal and Server installs of Fedora 23

[Pádraig Brady]

On 17/11/15 01:39, Stephen Gallagher wrote:
> (Please keep responses on the devel@ list; I've set it in the Reply-To.)
> 
> To jump right to the premise: The default Fedora Server install is Way
> Too Big(TM) and the minimal install (also available on the Fedora
> Server install media) is also Too Big.
> 
> I've been trying to do some quick-and-dirty analysis of what is in
> these default installations in order to figure out where we should be
> focusing our efforts. I'll point out that there are two goals that we
> need to keep in mind (and the reasons behind them) in order of
> increasing importance:
> 
> 1) Reduce disk space usage. While disk space on physical devices is
> becoming trivially cheap, disk space on Cloud deployments and rented
> virtual servers is still comparatively very expensive. We really want
> to minimize the amount of space that we use for Fedora so that users
> can fit their applications (the stuff they actually care about) into
> the remaining space without being forced to buy a larger storage
> allotment.
> 
> 2) Reduce maintenance efforts. Every additional piece of software on
> the system (referred to hereafter as "packages") increases the
> maintenance burden on an administrator. Universally, administrators
> prefer to have the smallest number of packages to maintain for a
> variety of reasons:
>  * Limiting update churn. The more packages on the system, the more
>often that one will need to run updates.
>  * Limiting security exposure. Every package on the system is another
>potential privilege-escalation point. Keeping this number under
>control means a reduced likelihood of a catastrophic breach. (The
>actual risk here is impossible to quantify, but it can be assumed
>that less code == less potential vulnerabilities.
>  * Non-expert administrators do not always know what is installed on
>their systems. This can lead to unintentional breaches as an
>admin doesn't realize that one or more services needs to be limited
>(such as in the firewall or via SELinux).
> 
> With these two goals in mind, the most obvious approach to improving
> this situation would be by reducing the number of packages installed
> by default on the Minimal and Fedora Server installs. As a specific
> goal of the Server Working Group, we want to aim for a world wherein
> administrators will no longer desire to install the Minimal install
> and instead will rely on the platform provided by the default Fedora
> Server install. They do not do this today because the Fedora Server
> installation is considerably larger. I postulate that this is due
> primarily to dependency bloat, which is where we should focus our
> efforts during the Fedora 24 timeframe. I postulate (but have not yet
> confirmed) that there are likely many places where we could replace
> Requires: with Recommends: (or even Suggests:) dependencies. In my
> ideal world, the difference between a Minimal and Server install would
> be identical to installing the same set of packages with Recommends:
> on or off.
> 
> 
> Some highlights of my initial research (with a lot of my raw data in
> the tarball attached to this email):
> 
> 
> == Minimal ==
> 
> === Disk Usage ===
> /boot: 79MB
> /: 755MB
> 
> 
> === Packages ===
> Total count: 270
> 
>  Largest 10 packages 
> 14288083: coreutils

We might create a coreutils-singlebin package that is built with
  ./configure --enable-single-binary
which would include only the single binary and stubs.
I think chromium is using this setup.
coreutils-singlebin could Recommends: coreutils-doc, while the
standard coreutils package would require coreutils-doc.
That would save about 13MB in the install.
Caveat is that the single binary would dynamically link
all shared libs, which associated startup and mem overhead.

cheers,
Pádraig
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Pádraig Brady]

On 23/09/15 18:19, Richard W.M. Jones wrote:
> On Tue, Sep 22, 2015 at 12:13:39PM -0400, Eric Griffith wrote:
>> Suggested way to upgrade from 22 to 23? Fresh install? Fedup? Change
>> release ver  for dnf? Did the new dnf upgrade tool get packaged?
> 
> I've done this on a number of machines (I would say at least 5):
> 
>   
> https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22_-.3E_Fedora_23
> 
> and it works fine.  You may hit a problem that the reboot command
> doesn't work immediately after the update (sorry, don't have the BZ or
> error message right now),

https://bugzilla.redhat.com/1229416

> but you can just do:
> 
>   sync
>   reboot -f
> 
> to work around that, and the reboot command works afterwards.

Yes it's an selinux issue. So I did:

  sync
  setenforce 0
  reboot

cheers,
Pádraig
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

[Pádraig Brady]

On 22/09/15 18:02, Stephen Gallagher wrote:
> On Tue, 2015-09-22 at 12:13 -0400, Eric Griffith wrote:
>> Suggested way to upgrade from 22 to 23? Fresh install? Fedup? Change
>> release ver  for dnf? Did the new dnf upgrade tool get packaged?
> 
> `dnf install dnf-plugin-system-upgrade`
> `dnf system-upgrade download --releasever=23`
> `dnf system-upgrade reboot`

I see the above has replaced fedup:
https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades

I just used dnf distro-sync as per:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22_-.3E_Fedora_23

This went fine, and I'm now typing this on F23 beta.
What are the main advantages of system-upgrade?
Should the above wiki mention the system-uprade instructions?

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Pádraig Brady]

On 21/09/15 16:07, Matthew Miller wrote:
> Fedora-Cloud-Base-20141203-21.x86_64.qcow2:   151M  
> Fedora-Cloud-Base-23_Beta-20150915.x86_64.qcow2:  275M
> 
> In just one year — 82% more awesome? 
> 
> I'd really like this to stay below 200MB as a competitive threshold.
> Or, if we're going to be bigger than that, be bigger for REASONS, not
> just accretion.
> 
> tl;dr: grub2 is a lot to blame, but there seem to be some new
> questionable dep chains from systemd, and general dep growth across the
> board.
> 
> 
> Disk use at first boot:
> 
>   [f21]$ df -h  /
>   Filesystem  Size  Used Avail Use% Mounted on
>   /dev/vda120G  359M   19G   2% /
> 
>   [f23b]$ df -h  /
>   Filesystem  Size  Used Avail Use% Mounted on
>   /dev/vda120G  578M   19G   4% /
> 
> RPMs installed:
> 
>   [f21]$ rpm -qa | wc -l
>   226
> 
>   [f23b]$ rpm -qa | wc -l
>   264
> 
> Top 20 rpms by reported size:
> 
>   $ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
>   120417342 glibc-common
>   42307839 kernel-core
>   25000497 python-libs
>   22438155 systemd
>   14623272 coreutils
>   14000291 glibc
>   11282056 ruby-libs  # hey, at least we lost this
>   10845519 glib2
>   10593004 selinux-policy-targeted
>   9389116 cracklib-dicts  # https://bugzilla.redhat.com/show_bug.cgi?id=865521
>   9078043 python-boto
>   8792531 util-linux
>   7084188 bash
>   6669884 gnupg2
>   5844544 yum
>   4893790 policycoreutils
>   3786564 file-libs
>   3540004 shadow-utils
>   3458312 groff-base  # who doesn't love groff?
>   2997717 tar
> 
> 
>   $ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
>   125195206 glibc-common
>   86298752 linux-firmware   # sadface, but hard
>   53291365 kernel-core
>   36004297 grub2-tools  # this is ridiculous
>   28453336 python3-libs # 13% growth
>   27233273 systemd  # 21% growth
>   16648994 grub2# *sigh*
>   14486819 glibc
>   14287847 coreutils# this package got _smaller!_

... and more secure, due to lots of hard work minimizing dependencies,
like using glibc's printf implementation rather than our own.
Thanks for noticing :)

Note coreutils also got a new ./configure --enable-single-binary
option recently to build all tools to a single binary like busybox.
The tradeoff is somewhat higher startup cost, and RAM cost,
due to all shared libs being linked. Chromium is using this
build configuration I understand.

cheers,
Pádraig.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Pádraig Brady]

On 10/09/15 14:53, Stephen Gallagher wrote:
> I assume that subject line got your attention.

> The reason for this proposal is relatively simple: we know the
> advantages to unbundling, particularly with security and resource-
> usage. However, the world's developer community largely *does not
> care*. We fought the good fight, we tried to bring people around to
> seeing our reasoning and we failed.

I'm not sure it follows that we compromise the advantages
of existing packaging processes.  How about we strive to
maintain clean separated packages, but where this is not practical
use container tech to provide the bundles?  That may involve
tighter integration of container registry with the app installer.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Package python-qpid is blocked for tag f24: how to unblock it?

[Pádraig Brady]

On 03/09/15 21:42, Irina Boverman wrote:
> - Original Message -
> From: "Pádraig Brady" 
>> I presume it was retired.
>> To unretire you've to file a ticket I think.
>> like this one for example:
>> https://fedorahosted.org/rel-eng/ticket/5592
> 
> I already "unretired" this package, and was able to check-in package changes, 
> but can't build it for rawhide/f24.

Which ticket?

Note the unblocking process which I guess is done
by those processing the ticket is documented at:
https://fedoraproject.org/wiki/Package_blocking_SOP

cheers,
Pádraig

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Package python-qpid is blocked for tag f24: how to unblock it?

[Pádraig Brady]

On 03/09/15 20:01, Irina Boverman wrote:
> BuildError: package python-qpid is blocked for tag f24
> 
> What do I need to do to unblock it?
> --
> Regards, Irina.
> --
> $ fedpkg build
> Building python-qpid-0.32-9.fc24 for rawhide
> Created task: 10944705
> Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=10944705
> Watching tasks (this may be safely interrupted)...
> 10944705 build (rawhide, 
> /python-qpid:d10fba32ce215ce0a6ef6b391e999e48366431d4): free
> 10944705 build (rawhide, 
> /python-qpid:d10fba32ce215ce0a6ef6b391e999e48366431d4): free -> open 
> (buildvm-06.phx2.fedoraproject.org)
>   10944706 buildSRPMFromSCM 
> (/python-qpid:d10fba32ce215ce0a6ef6b391e999e48366431d4): free
>   10944706 buildSRPMFromSCM 
> (/python-qpid:d10fba32ce215ce0a6ef6b391e999e48366431d4): free -> open 
> (arm02-builder22.arm.fedoraproject.org)
>   10944706 buildSRPMFromSCM 
> (/python-qpid:d10fba32ce215ce0a6ef6b391e999e48366431d4): open 
> (arm02-builder22.arm.fedoraproject.org) -> closed
>   0 free  1 open  1 done  0 failed
> 10944705 build (rawhide, 
> /python-qpid:d10fba32ce215ce0a6ef6b391e999e48366431d4): open 
> (buildvm-06.phx2.fedoraproject.org) -> FAILED: BuildError: package 
> python-qpid is blocked for tag f24
>   0 free  0 open  1 done  1 failed
> 
> 10944705 build (rawhide, 
> /python-qpid:d10fba32ce215ce0a6ef6b391e999e48366431d4) failed

I presume it was retired.
To unretire you've to file a ticket I think.
like this one for example:
https://fedorahosted.org/rel-eng/ticket/5592
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is %autosetup another unwanted baby of Fedora?

[Pádraig Brady]

On 13/07/15 15:01, Richard W.M. Jones wrote:
> On Mon, Jul 13, 2015 at 02:39:57PM +0200, Marcin Juszkiewicz wrote:
>> Hi
>>
>> When I moved to Fedora after years of doing Debian packages I
>> noticed that there is no such thing as patch management when it
>> comes to Fedora packages. Everyone is using %patch macro with files
>> of random patchlevel (some even use reverse patches).
> 
> While not answering your question about %autosetup, I want to say this
> bit isn't quite true.  Some packages use an external git repo for
> patch management, and create the 'Patch...' lines semi-automatically.
> (Similar to, but less weird than: https://wiki.debian.org/PackagingWithGit)
> 
> %autosetup only handles half of this use case.  TBH it handles the bit
> that was already quite easy to do -- ie. invoking 'git am'.
> 
> Copying the patches from git and inserting the Patch lines is the hard
> part, and it would be nice to have some standardized tooling for that,
> instead of everyone's homebrew 'copy-patches.sh' script.

maybe pull `rdopkg update-patches` into `fedpkg` ?

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: UTF-8 locale in rpm build

[Pádraig Brady]

On 11/05/15 04:43, Lars Seipel wrote:
> On Sun, May 10, 2015 at 09:02:31AM +0200, Matěj Cepl wrote:
>> Which part f C.UTF-8 is not covered by en_US.UTF-8?
> 
> Let's see:
> 
> % export LC_COLLATE=C
> % bash -c 'case b in [A-Z]) echo upper;; *) echo lower;; esac'
> lower
> 
> Ok. Now en_US.UTF-8:
> 
> % export LC_COLLATE=en_US.UTF-8
> % bash -c 'case b in [A-Z]) echo upper;; *) echo lower;; esac'
> upper
> 
> Right. The collation rules for en_US.UTF-8 would likely break build and
> test scripts in lots of packages.
> 
> Relevant bash bug:
> http://savannah.gnu.org/support/index.php?108609

Note bash can set globasciiranges (and will default to that at some stage).
libc is the best place to fix that issue of course. The non ASCII
ranges are fairly daft.

cheers,
Pádraig
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf caches

[Pádraig Brady]

On 24/04/15 10:40, Radek Holy wrote:
> - Original Message -
>> From: "Pádraig Brady" 
>> To: "Development discussions related to Fedora" 
>> 
>> Sent: Thursday, April 23, 2015 8:11:45 PM
>> Subject: Re: dnf caches
>>
>> On 23/04/15 18:44, drago01 wrote:
>>> On Thu, Apr 23, 2015 at 7:07 PM, Pádraig Brady  wrote:
>>>> My Fedora 22 system prompted me that there was a new coreutils package for
>>>> update.
>>>> Rather than clicking "restart and install" in the GUI I tried to:
>>>>
>>>>   # dnf install coreutils
>>>>   Using metadata from Tue Apr 21 19:54:02 2015 (1 day, 21:50:24 hours old)
>>>>   Package coreutils-8.23-8.fc22.x86_64 is already installed, skipping.
>>>>
>>>> Ok fair enough, the updating system is using a separate cache to dnf.
>>>> Not ideal, but anyway how do I update the dnf cache?
>>>> I tried:
>>>>
>>>>   # dnf check-update coreutils
>>>>   Using metadata from Thu Apr 23 17:42:54 2015 (0:01:19 hours old)
>>>>   coreutils.x86_64
>>>>
>>>> Given the above found the new coreutils, I thought an install
>>>> would now work, though unfortunately it doesn't.
>>>>
>>>> Shouldn't dnf be looking at the timestamps of the repo
>>>> in each invocation (without -C) and updating the metadata if needed?
>>>> I presume that's what yum does since I never had an issue with this.
>>>>
>>>> I tried explicitly cleaning the cache like this:
>>>>
>>>>   # dnf --disablerepo=* --enablerepo=updates clean metadata
>>>>   Cleaning repos: updates
>>>>   5 metadata files removed
>>>>   2 dbcache files removed
>>>>
>>>> How do I refresh the cache?
>>>
>>> dnf --refresh  ... where  can be install foo or update
>>> etc.
>>
>> Great thanks. BTW --refresh is mentioned but not described in dnf --help.
>> It would be could to add a description.
> 
> Could you please file a bug?

https://github.com/pixelb/dnf/pull/1

cheers,
Pádraig
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf caches

[Pádraig Brady]

On 23/04/15 18:44, drago01 wrote:
> On Thu, Apr 23, 2015 at 7:07 PM, Pádraig Brady  wrote:
>> My Fedora 22 system prompted me that there was a new coreutils package for 
>> update.
>> Rather than clicking "restart and install" in the GUI I tried to:
>>
>>   # dnf install coreutils
>>   Using metadata from Tue Apr 21 19:54:02 2015 (1 day, 21:50:24 hours old)
>>   Package coreutils-8.23-8.fc22.x86_64 is already installed, skipping.
>>
>> Ok fair enough, the updating system is using a separate cache to dnf.
>> Not ideal, but anyway how do I update the dnf cache?
>> I tried:
>>
>>   # dnf check-update coreutils
>>   Using metadata from Thu Apr 23 17:42:54 2015 (0:01:19 hours old)
>>   coreutils.x86_64
>>
>> Given the above found the new coreutils, I thought an install
>> would now work, though unfortunately it doesn't.
>>
>> Shouldn't dnf be looking at the timestamps of the repo
>> in each invocation (without -C) and updating the metadata if needed?
>> I presume that's what yum does since I never had an issue with this.
>>
>> I tried explicitly cleaning the cache like this:
>>
>>   # dnf --disablerepo=* --enablerepo=updates clean metadata
>>   Cleaning repos: updates
>>   5 metadata files removed
>>   2 dbcache files removed
>>
>> How do I refresh the cache?
> 
> dnf --refresh  ... where  can be install foo or update 
> etc.

Great thanks. BTW --refresh is mentioned but not described in dnf --help.
It would be could to add a description.

I also see that `dnf install` no longer updates a package,
I now need to:

  dnf --refresh upgrade coreutils

thanks!
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf caches

[Pádraig Brady]

On 23/04/15 18:46, Adam Williamson wrote:
> Branched releases (i.e. F22 at present) do not use the 'updates' repo,
> it is empty. Updates go from updates-testing to fedora when they are
> marked as stable. So you need to clean 'fedora', not 'updates'.

I had done that too, to no avail.

thanks,
Pádraig
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

dnf caches

[Pádraig Brady]

My Fedora 22 system prompted me that there was a new coreutils package for 
update.
Rather than clicking "restart and install" in the GUI I tried to:

  # dnf install coreutils
  Using metadata from Tue Apr 21 19:54:02 2015 (1 day, 21:50:24 hours old)
  Package coreutils-8.23-8.fc22.x86_64 is already installed, skipping.

Ok fair enough, the updating system is using a separate cache to dnf.
Not ideal, but anyway how do I update the dnf cache?
I tried:

  # dnf check-update coreutils
  Using metadata from Thu Apr 23 17:42:54 2015 (0:01:19 hours old)
  coreutils.x86_64

Given the above found the new coreutils, I thought an install
would now work, though unfortunately it doesn't.

Shouldn't dnf be looking at the timestamps of the repo
in each invocation (without -C) and updating the metadata if needed?
I presume that's what yum does since I never had an issue with this.

I tried explicitly cleaning the cache like this:

  # dnf --disablerepo=* --enablerepo=updates clean metadata
  Cleaning repos: updates
  5 metadata files removed
  2 dbcache files removed

How do I refresh the cache?
Why should I need to mess with it anyway?

thanks,
Pádraig.

p.s. If using yum legacy, does that in fact use another (3rd) cache?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: should we consider making CoDel the default to combat bufferbloat?

[Pádraig Brady]

On 28/03/15 04:40, Dennis Jacobfeuerborn wrote:
> On 28.03.2015 04:42, Zbigniew Jędrzejewski-Szmek wrote:
>> On Sat, Mar 28, 2015 at 12:34:35AM +, Pádraig Brady wrote:
>>> Following on from 
>>> http://thread.gmane.org/gmane.linux.redhat.fedora.kernel/5549
>>> Has there been any more consideration for enabling this by default?
>> It's the default in F22+:
>>
>> /usr/lib/sysctl.d/50-default.conf:net.core.default_qdisc = fq_codel
> 
> Are there any performance comparisons out there for fq_codel compared to
> let's say mq? Does fq_codel utilize multiple cores/nic-queues effectively?

The following is from Dave Taht  ...

mq is generally attached to several different hardware queues on the
device or device driver. Below it, is attached another qdisc to
actually manage the packets, the default being pfifo_fast unless
changed with the default qdisc sysctl.

Modern versions of the tc command will show you those underlying qdiscs [1],
and their stats. (which can be quite interesting, no matter the qdisc)

So the mq behavior as for multiple cpus (which is parallel) remains
the same regardless of the underlying qdisc. As for any inherent
per-cpu parallelization for fq_codel, no, there is none. ( I would
like one day to see the hashing and timestamping all done in parallel
on the rx path)

I note that having a ton of hardware queues is sometimes not as good
as having a single queue or a direct queue to cpu mapping, using
sch_fq or fq_codel. The underlying BQL buffering (and thus delay) is
additive per hardware queue, as are adding sch_fq/fq_codel buffers per
hardware queue, so it is quite possible you will get less latency and
better throughput with less or even 1, hardware queues, if you have
cpus and workloads that can drive that scenario well.

There was a long thread on netdev 6 months or so back comparing NFS
performance with hardware multi-queue (with hash collisions on the
limited number of hardware queues) vs sch_fq(unlimited queues) (or
fq_codel 1024 by default).  I can try to find that thread and
resulting paper if you like.

As always, I encourage folk to merely try it, and try using benchmarks
that test for latency with load, like netperf-wrapper, or pick your
favorite network stressing workload, see what happens, and get back to
the codel or bloat email lists with your results.

I generally find myself using a diffserv filter to distribute among
the hardware queues in many scenarios rather than something that does
it via 5 tuple.

[1]

d@lakshmi:~/git$ tc -s qdisc show dev wlan0
qdisc mq 0: root
 Sent 324546057 bytes 471799 pkt (dropped 0, overlimits 0 requeues 16)
 backlog 0b 0p requeues 16
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514
target 5.0ms interval 100.0ms ecn
 Sent 106456 bytes 1865 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514
target 5.0ms interval 100.0ms ecn
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514
target 5.0ms interval 100.0ms ecn
 Sent 324439601 bytes 469934 pkt (dropped 0, overlimits 0 requeues 16)
 backlog 0b 0p requeues 16
  maxpacket 1514 drop_overlimit 0 new_flow_count 632 ecn_mark 0
  new_flows_len 1 old_flows_len 0
qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514
target 5.0ms interval 100.0ms ecn
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0


-- Dave Täht Let's make wifi fast, less jittery and reliable again!
https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

should we consider making CoDel the default to combat bufferbloat?

[Pádraig Brady]

Following on from http://thread.gmane.org/gmane.linux.redhat.fedora.kernel/5549
Has there been any more consideration for enabling this by default?

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Captive portal detection on wired connections - bug or feature?

[Pádraig Brady]

On 26/03/15 17:50, Dan Williams wrote:
> On Thu, 2015-03-26 at 18:29 +0200, Alexander Ploumistos wrote:
>> On Thu, Mar 26, 2015 at 6:24 PM, Bastien Nocera  wrote:
>>
>>> You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to
>>> disable it.
>>>
>>
>> Is there a *proper* way to do that so that there aren't any conflicts with
>> future updates, e.g. commenting the lines out, removing/renaming the file,
>> setting the interval to 0, etc.?
> 
> As Adam implied, you can add your own, higher-numbered file with the
> same options and NM will use those in preference to the Fedora-installed
> one.  See 'man NetworkManager.conf' for specifics.
> 
> ---
>If a default NetworkManager.conf is provided by your
> distribution's packages, you should not modify it, since your changes
> may get overwritten by
>package updates. Instead, you can add additional .conf files to
> the conf.d directory. These will be read in order, with later files
> overriding
>earlier ones.
> ---
> 
> Sorting of filenames is strcmp()-style, so 90-my-stuff.conf takes
> precedence over 10-bad-stuff.conf.

There are still quite a few unknowns.
To summarise, does this locally disable?

  crudini --set /etc/NetworkManager/conf.d/21-connectivity-local.conf 
connectivity interval 0
  systemctl reload NetworkManager

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Changes in the f22 workstation

[Pádraig Brady]

On 20/02/15 21:09, Matthias Clasen wrote:
> I wanted to give a heads-up to the wider audience about a number of 
> workstation changes that are landing in the f22 branch (and rawhide) 
> this week, in time for the alpha freeze next week:
> 
> - The message tray at the bottom is gone, notifications are now shown 
> at the top, and can be reviewed in the calendar popup (
> https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications)

This does seem like an improvement, following the general improvement
in notifications with each release.

However I'm surprised that there is still no mention of a permanent indicator
in the top bar, that notifications are present. This can be achieved with an
extension, but with large changes to notifications happening now, it would
seem like an ideal time to also introduce that change.
If you drill down through the comments at the above URL, you get to this:
https://bugzilla.gnome.org/show_bug.cgi?id=641723

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How many users does Fedora have?

[Pádraig Brady]

On 02/12/14 18:12, Stephen John Smoogen wrote:
> 
> 
> On 2 December 2014 at 09:22, Matthew Miller  > wrote:
> 
> On Tue, Dec 02, 2014 at 05:15:38PM +0100, jfm...@free.fr 
>  wrote:
> > Now it seems Fedora's downloads have been steadily going downwards
> > and it is highly improbable that is due to a spectacular increase of
> > number of people setting local mirrors.
> 
> Smooge is working on some updated statistics, and from what I've seen,
> it's mostly flat, but not actually steadily downwards. More on the
> other things later. :)
> 
> 
> 
> Temporary URL for picture of things from 2007 til last month:
> 
> https://smooge.fedorapeople.org/stats-2014/
> 
> I am hoping to have a permanent url and updated set by next month.

Good info thanks.
I think it would be worth splitting the Fedora and EPEL graphs.
(I presume that's why the second graph goes to 800K while the first
only goes to 200K).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How many developers Fedora has

[Pádraig Brady]

On 29/11/14 09:44, Ali AlipourR wrote:
> Hi
> Is there any statistics about How many developers Fedora has?

Considering just packages:
https://www.openhub.net/p/fedora-packages

Of course there are many more behind the scenes of the programs themselves.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Really making fonts awesome in Fedora 21

[Pádraig Brady]

I was surprised at the blurriness of the _default_ font (Cantarell) on my new 
F21 install.

There were noticeable artefacts as well as general blurriness
with no noticeable difference between grayscale and rgba antialiasing.
Even worse was different text heights for bold and normal which
was immediately evident with text jumping around as I traversed
my thunderbird unread message list.

I used gnome-tweak-tool to change all Cantarell to Sans and the
experience was _much_ better. BTW size 10 was much better proportioned
on my 1920x1080 screen, than the default size of 11.

I went digging on the Cantarell issue and it seems to be
the only one affected due to the CFF renderer in freetype >= 2.5
  https://bugzilla.redhat.com/show_bug.cgi?id=1035486

You can change most of the default fonts with gnome-tweak-tool
though the setting for the default font must be manually edited as per:
  http://rlog.rgtti.com/2012/01/29/how-to-modify-a-gnome-shell-theme/

Note also that chrome seems to honour GTK2 settings only:
  https://code.google.com/p/chromium/issues/detail?id=375824

So while issues can be worked around, it's awkward
and the default experience should be getter IMHO.

Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unannounced libunistring soname bump

[Pádraig Brady]

On 09/02/2014 04:12 PM, Dennis Gilmore wrote:
> On Tue, 02 Sep 2014 15:04:14 +0100
> Pádraig Brady  wrote:
> 
>> On 09/02/2014 01:08 PM, Dennis Gilmore wrote:
>>> Hi All,
>>>
>>> there was a new build of libunistring today [1][2] which braought
>>> along with it a soname bump from libunistring.so.0 to
>>> libunistring.so.2
>>>
>>> On a f21 box repoquery tells me that 
>>> bigloo-0:4.1a-5.2.fc21.armv7hl
>>> bigloo-libs-0:4.1a-5.2.fc21.armv7hl
>>> freeipa-server-0:4.0.1-1.fc21.armv7hl
>>> gettext-0:0.19.2-2.fc21.armv7hl
>>> gettext-libs-0:0.19.2-2.fc21.armv7hl
>>> gssntlmssp-0:0.5.0-2.fc21.armv7hl
>>> guile-5:2.0.11-3.fc21.armv7hl
>>> hop-0:2.5.0-1.fc21.2.armv7hl
>>> libunistring-devel-0:0.9.3-11.fc21.armv7hl
>>> rygel-0:0.23.3.1-1.fc21.armv7hl
>>> wcd-0:5.2.5-3.fc21.armv7hl
>>>
>>> use libunistring.so.0 I have sent a build for gettext as its has
>>> broken things, It will need extra care and a buildroot override on
>>> f21 to be dealt with.
>>>
>>> Dennis
>>>
>>> [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=574600
>>> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=574599
> 
>> Oops sorry I missed the soname bump.
>> I can revert/untag the F21 build if that helps?
> 
> The f21 build is not in the buildroot, it won't be until the build goes
> stable or you make a buildroot override for it. the rest of the
> packages in rawhide should be rebuilt. you cant get it in f21 but make
> sure you use a buildroot override and submit all packages as a single
> update.

Ah right, I was thinking it would be harder to break F21 :)
I've reverted the F21 update and the above are all rebuilt on rawhide.

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unannounced libunistring soname bump

[Pádraig Brady]

On 09/02/2014 01:08 PM, Dennis Gilmore wrote:
> Hi All,
> 
> there was a new build of libunistring today [1][2] which braought along
> with it a soname bump from libunistring.so.0 to libunistring.so.2
> 
> On a f21 box repoquery tells me that 
> bigloo-0:4.1a-5.2.fc21.armv7hl
> bigloo-libs-0:4.1a-5.2.fc21.armv7hl
> freeipa-server-0:4.0.1-1.fc21.armv7hl
> gettext-0:0.19.2-2.fc21.armv7hl
> gettext-libs-0:0.19.2-2.fc21.armv7hl
> gssntlmssp-0:0.5.0-2.fc21.armv7hl
> guile-5:2.0.11-3.fc21.armv7hl
> hop-0:2.5.0-1.fc21.2.armv7hl
> libunistring-devel-0:0.9.3-11.fc21.armv7hl
> rygel-0:0.23.3.1-1.fc21.armv7hl
> wcd-0:5.2.5-3.fc21.armv7hl
> 
> use libunistring.so.0 I have sent a build for gettext as its has broken
> things, It will need extra care and a buildroot override on f21 to be
> dealt with.
> 
> Dennis
> 
> [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=574600
> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=574599

Oops sorry I missed the soname bump.
I can revert/untag the F21 build if that helps?

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Replace Yum With DNF

[Pádraig Brady]

On 06/11/2014 04:41 PM, Reindl Harald wrote:
> 
> Am 11.06.2014 17:37, schrieb Chuck Anderson:
>> Have puppet, chef, ansible, salt, etc. been taught how to use "dnf" to
>> install packages?  I think it would be a shame to force all this
>> software to do s/yum/dnf/ or to have to conditionally code for these
>> differences based on OS release or the presense of yum vs. dnf.  Why
>> not just keep the command name the same with no nag message?
> 
> because it is not state of the art to change things in a
> way that the change is not heavily noticed to point out
> "look we have done something and now it's your turn"
> 
> hopefully coreutils will not get a replacement in the next
> cycle with the commands "move", "copy", "removedir", "Listddir"
> and obsolete "mv", "cp", "rmdir", "ls"

Good idea, they're clearer.
I'll do that in the coming release.

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Service units for web applications

[Pádraig Brady]

On 02/25/2014 08:07 PM, Lennart Poettering wrote:
> On Tue, 25.02.14 14:55, Stephen Gallagher (sgall...@redhat.com) wrote:
> 
>> There are actually two pieces to this that I'd like to see (and
>> hopefully have someone tell me are already possible):
>>
>>  1. The ability to add new ExecStartPre commands to the httpd service
>> when installing new sites.
> 
> You can do that already, you can extend existing unit files by dropping
> a config snippet into httpd.service.d/foobar.conf. systemd will
> read httpd.service plus all files named *.conf from httpd.service.d/ and
> merge them together. THis can be used by RPMs to change or extend unit
> files of other packages as necessary.
> 
>>  2. The ability to enable and disable specific apache sites from
>> systemctl. Basically, I'd like to have a symlink added or removed
>> from /etc/httpd/conf.d based on whether httpd-mysite.service was
>> enabled or disabled.
> 
> I am pretty sure that systemctl should not be in the business of
> managing other packages configuation.

Debian land has a2ensite and a2dissite for this.
Any reason not just to make those available from the httpd package like debian 
does?

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Pádraig Brady]

On 11/19/2013 10:55 AM, Mathieu Bridon wrote:
> On Tue, 2013-11-19 at 10:32 +, Richard W.M. Jones wrote:
>> On Tue, Nov 19, 2013 at 06:28:47PM +0800, Mathieu Bridon wrote:
>>> Or maybe we could start using %autosetup ?
>>>
>>>   http://www.rpm.org/wiki/PackagerDocs/Autosetup
>>
>> '%autosetup -S git' for sure, not plain %autosetup.
>>
>> Git correctly handles file modes and binary patches (not that binary
>> patches should be much of a concern here, but file modes definitely
>> are).

BTW patch 2.7 does support file mode changes:
http://savannah.gnu.org/forum/forum.php?forum_id=7361

Binary patches are not yet supported but they are quite useful
and I've hit that with patches adding new png files for example.

On the topic of new files, `%autosetup -S git` currently doesn't handle those:
https://bugzilla.redhat.com/1059285

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: TLS libraries and licenses

[Pádraig Brady]

On 11/27/2013 09:16 PM, Jerry James wrote:
> On Wed, Nov 27, 2013 at 10:51 AM, Rex Dieter  wrote:
>> Jerry James wrote:
>>
>>> The third option is OpenSSL, whose license is GPL-incompatible, and so
>>> not an option for us.
>>
>> at least in fedora, openssl is considered a "system library" (for gpl
>> purposes).
>>
>> Probably a good idea to consult fedora legal list instead (you'll likely get
>> a better answer there)
>>
>> -- Rex
> 
> Some of my fellow developers want to steer away from openssl because
> of its license.  That Fedora considers it okay is unlikely to change
> their minds, but I'll mention it.  Thank you!

If it was an optional dependency you have more possiblity to
use openssl from GPL, as you would only need to use it on
those systems where openssl was already available.
If you want to support systems "other systems" and have
a hard dependency on this lib, you might have issues.

http://www.openssl.org/support/faq.html#LEGAL2
http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Pádraig Brady]

This is definitely worth formalizing.

On 11/19/2013 10:22 AM, Richard W.M. Jones wrote:
> Several packages are using git for patch management.  eg:
> 
> http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46
> http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22
> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/
> http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16

All the OpenStack packages also use this technique too:
Specifically you use a comment of the form to mark the auto generated patches:
 # patches_base=$tag
For example see:

http://pkgs.fedoraproject.org/cgit/openstack-nova.git/tree/openstack-nova.spec#n37

One can also add an optional +number to skip that many patches after a tag,
which we found useful in various cases.

> Some of these packages have invented home-brewed methods to generate
> the Patch lines in the spec file, eg:
> 
> http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh
> http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20

https://github.com/redhat-openstack/redhat-openstack.github.com/blob/scripts/update-patches.sh

> More importantly, all are using random git repositories to store the
> exploded tree.  This makes it difficult for co-maintainers and proven
> packagers to fit in with the patch management chosen by the
> maintainer.  Usually they won't have access to the git repository for
> these patches, making it difficult to add patches and near impossible
> to upgrade to a new version.
> 
> I think that git is an excellent way to manage patches, but we ought
> to think about formalizing this process.  I think the goals should be:
> 
> (1) A git repository is used that co-maintainers and proven packagers
> automatically have access to.

This would be the crux of formalizing this.

For the OpenStack packages we use a separate github organisation
to manage this (as well as other things):

http://github.com/redhat-openstack/

> (2) A single method & script is used to update the patches in the spec file.
> 
> Although there is already a git repository satisfying (1) above,
> namely dist-git, it isn't suitable for storing the exploded tree since
> commits to the spec file would conflict with commits (patches) to the
> tree.  So either a separate side repository which packages could
> opt-in to, or perhaps a separate branch of the same git repo could be
> used.  I think using a branch would require no additional
> infrastructure.
> 
> For (2) I would suggest a lightweight technique where git-managed
> patches are marked in the spec file using:
> 
>   ### GIT-MANAGED-PATCHES ###
>   ### END-GIT-MANGED-PATCHES ###
> 
> and a simple script that replaces everything between those marks with
> Patch lines.  The script could be adapted from copy-patches.sh
> (see above).
> 
> To apply the patches, a standard RPM macro could be created:
> 
>   %prep
>   %setup -q
>   %{git_apply_patches}
> 
> which would expand to something like:
> 
>   git init
>   git config user.email "%{name}-ow...@fedoraproject.org"
>   git config user.name "%{name}"
>   git add .
>   git commit -a -q -m "%{version} baseline"
>   git am %{patches}
> 
> Thoughts on this?

Using patch(1) to apply patches mostly works with a few caveats
(binary patches come to mind). Using git to apply is a new dependency
but also the most general method for applying.

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: LVM thin provisioning and virt-manager

[Pádraig Brady]

On 10/17/2013 07:09 PM, Chris Murphy wrote:
> 
> On Oct 17, 2013, at 10:22 AM, Chris Murphy  wrote:
> 
>>
>> So whatever options virt-manager is using to create qcow2 files, is either 
>> the same as -o preallocation=metadata,compat=1.1,lazy_refcounts=on, or any 
>> difference in options isn't making a difference in performance. The 37 
>> second performance difference is probably due to less disk contention from 
>> the source ISO being on a separate drive this time around. And if I'm right 
>> about all of that, then the overwhelming gain is coming from unsafe cache.
> 
> My original 1h41s result I reported was based on a qcow2 file that I made 
> using qemu-img without metadata preallocation, not the virt-manager UI. So 
> the above assertion that most gain is coming from unsafe cache was premature.
> 
> Here's the retesting:
> 
> btrfs partitions default guided to qcow2 (libvirt unsafe cache, virt-manager 
> default qcow2 creation)
> anaconda.log "Running Thread: AnaInstallThread" = 15:56:02
> anaconda.log "Thread Done: AnaConfigurationThread" = 16:12:46
> 00:16:44
> 
> btrfs partitions default guided to qcow2 (libvirt unsafe cache, qemu-img 
> qcow2 creation with no options)
> anaconda.log "Running Thread: AnaInstallThread" = 17:18:10
> anaconda.log "Thread Done: AnaConfigurationThread" = 17:35:23
> 00:17:13
> 
> That's significantly more justification to suggest most of the gain over the 
> first 1h41m case was overwhelming due to the use of the 'none' cache setting; 
> and qcow2 metadata preallocation is not nearly as significant a factor.

Yes preallocation=metadata makes a huge difference.
I've testing benchmarks here:
https://blueprints.launchpad.net/nova/+spec/preallocated-images
Note the caveats with backing disk though.

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Suggestion: bmap files and bmaptool

[Pádraig Brady]

On 08/16/2013 09:46 AM, Artem Bityutskiy wrote:
> Hi Eric,
> 
> thanks for the question. Sorry my answers contain extra information, but
> I assume that other people read this, and may benefit from the info.
> After all, I am trying to get people interested, this is a good tool
> IMO, and I would like to get more users and hopefully contributors. :-)
> 
> On Thu, 2013-08-15 at 12:34 -0500, Eric Sandeen wrote:
>> On 8/13/13 8:58 AM, Artem Bityutskiy wrote:
>>> # Make the image to be sparse
>>> $ cp --sparse=always Fedora-x86_64-19-20130627-sda.raw
>> Fedora-x86_64-19-20130627-sda.raw.sparse
>>>
>>> # Generate the bmap file
>>> $ bmaptool create Fedora-x86_64-19-20130627-sda.raw.sparse -o
>> Fedora-x86_64-19-20130627-sda.raw.sparse.bmap
>>
>> So this is the part that interests me . . .
> 
> Before going further, I want to quckly note that the Tizen image
> generation software uses the BmapCreate library API directly, instead of
> running the bmaptool command-line utility. The library comes with the
> bmap-tools project.
> 
> http://git.infradead.org/users/dedekind/bmap-tools.git/blob/refs/heads/devel:/bmaptools/BmapCreate.py
> 
>> There seem to be two issues here; how do we efficiently (compress and)
>> transport sparse files while retaining sparseness, and how do we
>> efficiently operate on files which are already sparse.
> 
> Yes, it is our assumption is that sparseness gets lost as soon as the
> image is  compressed or copied to the download server, or anywhere else.
> 
> The idea is that as soon as you generate the raw image on the build
> server, you generate the bmap file right away, _before_ the sparseness
> gets lost.
> 
> The sparseness information is then saved in the bmap file. Then you can
> compress the image, copy it around, and lose the sparseness. The bmap
> file preserves it.
> 
> And of course this means that you should not modify the image later on,
> otherwise the bmap file becomes incorrect, and the checksums, which are
> inside the bmap file, will probably mismatch.
> 
>> For the latter, you're using your bmap tool to map what is hopefully a
>> static file (via fibmap or fiemap, I guess?).
> 
> Yes, we use FIEMAP. Here is the python module which does the job:
> 
> http://git.infradead.org/users/dedekind/bmap-tools.git/blob/refs/heads/devel:/bmaptools/Fiemap.py
> 
>> I haven't looked at how you've done it, but you do need to be very
>> careful that the file is stable & quiesced on disk.
> 
> Right. We generate the bmap file on the _build server_, inside the tool
> which generates the raw image. At this point we do know we fully control
> the image, and no one touches it while we generate the bmap.
> 
> But yes, this is a good point, may be I need to put it to the man page.
> Which, by the way, as I figure out now, needs to be somewhat updated:
> 
> http://git.infradead.org/users/dedekind/bmap-tools.git/blob/refs/heads/devel:/docs/man1/bmaptool.1
> 
>>   Mapping it this way can be fraught with errors if the file is
>> changing, or has delalloc blocks, etc.
> 
> Good point. Tizen image generator fsync()'s the file before creating
> bmap, but I guess I have to do this in the BmapCreate library too, to be
> safe.
> 
> Thanks!
> 
>>   And of course getting the mapping wrong means data corruption.
> 
> Right. But as I said, we are using bmaptool for a year now, and nothing
> which looks like a corruption was reported so far.
> 
> But the importance of fsync() is a very good point, I'll improve the
> library and make it explicitely fsync, and probably ignore the EROFS
> error, in case the file is R/O.
> 
>>   If the file is known to be sparse, then going forward, using
>> SEEK_HOLE / SEEK_DATA is probably the best approach.
> 
> Why are they better than FIEMAP?
> 
> I did consider them, actually, but they are very new, and build servers
> tend to use older kernels, so I chose FIEMAP. I actually first used
> FIBMAP, but it is too slow, so I switched to FIEMAP.
>>
>> But then there's the issue of transporting these sparse files around.
>> We have had the same problem in the past with large e2image metadata
>> image files, which may be terabytes in length, with only gigabytes or
>> megabytes of real data.  e2image _itself_ creates a sparse file, but
>> bzipping it or rsyncing it still processes terabytes of zeros, and
>> loses all notion of sparseness.
> 
> Right, but the scenario I keep in mind is that the bmap file is created
> at the _very_ beginning, and carried/published together with the image,
> as a stand-alone file with the same basename and ".bmap" extension.
> 
> The zeroes in the image can be very well compressed with xz, so people
> download/copy a lot less than Terabytes. And then people just run this
> command to re-create the original sparse file:
> 
> $ bmaptool copy --bmap huge.img.bmap huge.img.xz a_sparse_copy.img
> 
> This will decompress huge.img.xz on-the-fly and put it to
> a_sparse_copy.img. The a_sparse_copy.img file will be sparse.
> 
> Note, it bmaptool auto-discovers 

Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

[Pádraig Brady]

On 07/26/2013 09:13 PM, Miloslav Trmač wrote:
> Hello all,
> with thin provisioning available, the total and free space values
> reported by a filesystem do not necessarily mean that that much space
> is _actually_ available (the actual backing storage may be smaller, or
> shared with other filesystems).
> 
> If your package reports disk space usage to users, and bases this on
> filesystem free space, please consider whether it might need to take
> LVM thin provisioning into account.
> 
> The same applies if your package automatically allocates a certain
> proportion of the total or available space.
> 
> A quick way to check whether your package is likely to be affected, is
> to look for statfs() or statvfs() calls in C, or the equivalent in
> your higher-level library / programming language.

Anything df(1) should do here?


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Grepping through all Fedora specfiles?

[Pádraig Brady]

On 07/23/2013 07:47 PM, Ville Skyttä wrote:
> On 2013-07-22 18:55, Thomas Moschny wrote:
>>
>> Maybe you could use searchco.de in some creative way?
>>   http://searchcode.com/?q=url%3Afedora+ext%3Aspec+docdir
> 
> Thanks for the pointer -- but what makes that less useful than it could
> be is that the url parameter is ignored if searching with a regexp. The
> service provider is aware of this and it should be fixed sometime.

I've been informed that this is now fixed.
http://searchcode.com/?q=/[cb]at/+url:fedora+ext:spec

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GCC -fdiagnostics-color= default

[Pádraig Brady]

On 05/27/2013 06:16 PM, John Reiser wrote:
>> gcc 4.8.0-6.fc19 and later contains a backport of color diagnostics
>> support from gcc trunk.  ...
>> Would users appreciate it being done by default (i.e. make
>> -fdiagnostics-color=auto the default)?
> 
>>> * Any pros/cons?
> 
>> Same thing as pros/cons of colorizing grep or ls output by default.
> 
> Let's make an explicit list.  Here is a start:
> 
> 0. Supposedly the colors provide faster visual communication, increased ease
>of recognition and understanding, etc.: an "enhancement".
> 
> 1. Background color matters.  The default colors are chosen for a black 
> background.
>On a white background some of the default colors may be more difficult
>to process visually.  For example, on a white background I find it
>much harder to recognize and process the green caret under the terminating
>right brace of "test.C:1:14: warning: no return statement in function 
> returning non-void [-Wreturn-type]
>  int foo () { }"  in http://gcc.gnu.org/gcc-4.9/changes.html (C family 
> section).

Note 256 colors are supported by default since Fedora 18
and give much more choice for colors that are appropriate
for light or dark backgrounds:
http://fedoraproject.org/wiki/Features/256_Color_Terminals

> 
> 2. Changing the default colors is cumbersome.  Remembering how to turn off
>the colorization is another straw on the user's back.
> 
> 3. Redirecting stderr to a non-terminal changes the error message.
>(Configurable; but it is another straw.)
> 
> 4. The bugs in colorized presentation of error messages may be different
>than in non-colorized presentation.
> 
> 5. No attention has been paid to how colorization affects persons
>who have color blindness or other visual disabilities.
> 
> 6. Colorization is not being presented as a plugin which uses the API
>for gcc's warning subsystem.  Is colorization such a plugin?  Why not?
>How does colorization interact with an existing use of the API for
>gcc's warning subsystem?
> 

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

Re: F19 DVD over size - what to drop?

[Pádraig Brady]

On 05/01/2013 09:03 PM, Bill Nottingham wrote:
> The F19 DVD is currently *way* over size. (i686: 417MB, x86_64: 311MB).
> That's almost certainly more than can be fixed by trimming around the
> edges; we need to remove actual functionality that's on the DVD.
> 
> Options include:
> 
> 1) One/some of the desktops
> 
> F19 DVD currently includes
> - GNOME
> - KDE
> - XFCE
> - LXDE
> - Sugar
> - MATE (new in F19)
> - Cinnamon (new in F19)
> 
> 2) The web server environment
> 
> Contains web server and web server runtimes (PHP, JBoss, Mongo, perl,
> python, rails)
> 
> 3) The developer & content creator workstation
> 
> Contains the web server stuff above, Eclipse, developer tools, designer
> tools, Fedora packaging tools, and so on.
> 
> Opinions?

Why are we tied to DVD-5, 4.7GB (4.3GiB) at all?
Do we distribute DVDs?
If so couldn't we use a newer DVD standard?
I can't see any users wanting to burn DVDs
rather than using USB sticks etc.

I'd be more inclined to align stuff at 1GB, 4GB, 8GB
to fit in USB media.

Larger media is a bit questionable anyway,
since it's means more stuff gets out of date.

I notice for F18, each particular desktop spin seems to fit in 1GB:
http://alt.fedoraproject.org/pub/alt/live-respins/
All the source requires DVD-9 (8.5GB), but again that's of marginal value.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Fedora 19 Alpha Test Compose 2 (TC2) Available Now!

[Pádraig Brady]

On 03/28/2013 04:54 PM, Pádraig Brady wrote:
> On 03/28/2013 02:24 PM, Pádraig Brady wrote:
>> On 03/26/2013 04:17 AM, Andre Robatino wrote:
>>> *IMPORTANT*: All DVDs and Lives are oversized, so will not fit on the
>>> standard media.
>>
>> To save others wasted time, please note that TC2 is not installable on bare 
>> metal:
>> https://bugzilla.redhat.com/show_bug.cgi?id=928228
>>
>> Also when installing to a VM, 1G is not enough RAM at least,
>> and will result in tending towards infinite CPU spin in anaconda/loop2/loop3
>> when one clicks the "install to hard drive" icon.
>> A 2G VM is working for me now.
> 
> Lest you waste more time trying to install to the default
> 8G virt-manager provided disk image, with ultra confusing errors,
> it seems you need about 16G:
> https://bugzilla.redhat.com/show_bug.cgi?id=928886

So the install worked with the above but the boot hung
with systemd complaining it couldn't find /run.
The system booted fully after a quick workaround using:
https://bugzilla.redhat.com/show_bug.cgi?id=922988#c27

Now I see the display has blanked can't be restored:
So looks like one needs to immediately:
  settings -> privacy -> screen lock -> off
  settings -> power -> screen blank -> never
https://bugzilla.redhat.com/show_bug.cgi?id=923364
(Note pressing esc doesn't work for me)

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Fedora 19 Alpha Test Compose 2 (TC2) Available Now!

[Pádraig Brady]

On 03/28/2013 02:24 PM, Pádraig Brady wrote:
> On 03/26/2013 04:17 AM, Andre Robatino wrote:
>> *IMPORTANT*: All DVDs and Lives are oversized, so will not fit on the
>> standard media.
> 
> To save others wasted time, please note that TC2 is not installable on bare 
> metal:
> https://bugzilla.redhat.com/show_bug.cgi?id=928228
> 
> Also when installing to a VM, 1G is not enough RAM at least,
> and will result in tending towards infinite CPU spin in anaconda/loop2/loop3
> when one clicks the "install to hard drive" icon.
> A 2G VM is working for me now.

Lest you waste more time trying to install to the default
8G virt-manager provided disk image, with ultra confusing errors,
it seems you need about 16G:
https://bugzilla.redhat.com/show_bug.cgi?id=928886

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Fedora 19 Alpha Test Compose 2 (TC2) Available Now!

[Pádraig Brady]

On 03/26/2013 04:17 AM, Andre Robatino wrote:
> *IMPORTANT*: All DVDs and Lives are oversized, so will not fit on the
> standard media.

To save others wasted time, please note that TC2 is not installable on bare 
metal:
https://bugzilla.redhat.com/show_bug.cgi?id=928228

Also when installing to a VM, 1G is not enough RAM at least,
and will result in tending towards infinite CPU spin in anaconda/loop2/loop3
when one clicks the "install to hard drive" icon.
A 2G VM is working for me now.

> As per the Fedora 19 schedule [1], Fedora 19 Alpha Test Compose 2 (TC2)
> is now available for testing. Content information, including changes,
> can be found at https://fedorahosted.org/rel-eng/ticket/5545#comment:3 .
> Please see the following pages for download links (including delta ISOs)
> and testing instructions. Normally dl.fedoraproject.org should provide
> the fastest download, but download-ib01.fedoraproject.org is available
> as a mirror (with an approximately 1 hour lag) in case of trouble. To
> use it, just replace "dl" with "download-ib01" in the download URL.

As aid to people quickly scanning email, please markup URLs
so they're clickable, like:

https://dl.fedoraproject.org/pub/alt/stage/
https://download-ib01.fedoraproject.org/pub/alt/stage/ (mirror (1 hour lag))

thanks,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Keystone on Rawhide tracebacks around sqlalchemy

[Pádraig Brady]

On 02/19/2013 12:56 AM, Pete Zaitcev wrote:

Greetings:

When I try to run Keystone, it blows up with this:

   File "/usr/lib/python2.7/site-packages/migrate/versioning/schema.py", line 10, in 

 from sqlalchemy import exceptions as sa_exceptions
ImportError: cannot import name exceptions

python-sqlalchemy-0.8.0-0.1.b1.fc19.x86_64
openstack-keystone-2013.1-0.2.g2.fc19.noarch

Weird thing is, I'm not trying to migrate anything anywhere.
Just launching a new Keystone with "keystone-manage db_sync".
Does it work for anyone else?


That's awkward.  0.8.0 is currently incompat with openstack.
I suggest downgrading python-sqlalchemy to the 0.7 series for now

thanks,
Pádraig.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Command line arguments depend on locale

[Pádraig Brady]

On 01/31/2013 06:01 PM, Matthias Clasen wrote:

- Original Message 


Right, output should be locale specific. Input command line args...
seems
specious.


Until you put a pipe between and turn the outputs of command a into inputs of 
command b...



It's a fair point.

I.E. I/O doesn't round trip here:

$ LC_NUMERIC=de_DE env printf "%f\n" 0.1 $(LC_NUMERIC=de_DE env printf "%f\n" 
0.1)
0,10
printf: 0,10: value not completely converted
0,00

I suppose commands might only enable locale specific output if
output is to a tty, though that brings other inconsistencies.

thanks,
Pádraig.

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

Re: Command line arguments depend on locale

[Pádraig Brady]

On 01/30/2013 11:05 PM, Benny Amorsen wrote:

Apparently ping has now started interpreting its command line arguments
depending on locale. I.e. ping -i 0.1 no longer works in locales where
comma is the decimal separator.

This makes it difficult to call system commands. The only workaround is
to set LC_ALL to a known-good locale, but then your users get no benefit
from the translations of error messages and so on.

Is Linux really doomed to repeat the mistakes made by Visual Basic more
than a decade ago?


Yes this is a slippery slope.
ping is definitely wrong to do this IMHO.

A less clear cut example is printf(1).
POSIX states that LC_NUMERIC controls the format
of the numbers _written_.
In coreutils we're careful to reset to the C locale
so that strtod etc. work consistently.

Just testing bash here shows it was a different interpretation
which I would deem not what POSIX intended:

# coreutils
$ LC_NUMERIC=de_DE env printf "%f\n" 0.1
0,10
$ LC_NUMERIC=de_DE env printf "%f\n" 0,1
printf: 0,1: value not completely converted
0,00

# bash
$ LC_NUMERIC=de_DE printf "%f\n" 0,1
0,10
$ LC_NUMERIC=de_DE printf "%f\n" 0.1
bash: printf: 0.1: invalid number
0,00

cheers,
Pádraig
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: OpenStack Grizzly

[Pádraig Brady]

On 01/23/2013 09:42 PM, Bill Nottingham wrote:

Michael Scherer (m...@zarb.org) said:

While it may be harder to predict the feature that will land in
Openstack at this point, would it be possible to have at least a idea of
the new features and changes that such upgrade will bring ?

It is hard to say if this is a good idea or not without it, and hard to
write a good marketing pitch based on this.


The desktop features usually do some of this, where they mention not just
the new version, but the major improvements in that new version.


I'd already included a summary of major new features in the release notes 
section:
https://fedoraproject.org/wiki/Features/OpenStack_Grizzly#Release_Notes
We'll continue to update as the release approaches.


Also, I note: "Upgrades from Folsom to Grizzly may need significant upstream
work to achieve."  Do we know what sort of work this may imply?


So in summary fully live upgrade probably wont be possible
for grizzly, but the upgrade procedure should at least be simplified.

Here are notes on Diablo -> Essex which was an awkward transition:
https://lists.launchpad.net/openstack/msg16199.html

Here are notes on upgrading Essex to Folsom which is better:
https://fedoraproject.org/wiki/Talk:Getting_started_with_OpenStack_EPEL

Here are related notes from the last OpenStack Design summit
detailing planned improvements to Grizzly in this area:
https://etherpad.openstack.org/grizzly-live-upgrade
https://etherpad.openstack.org/GrizzlyUpgradeGrenade
https://etherpad.openstack.org/grizzly-quantum-upgrade-path

thanks,
Pádraig.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New Online search for the Fedora Source

[Pádraig Brady]

On 11/30/2012 12:09 PM, Pádraig Brady wrote:

Benjamin Boyter has recently indexed the entire Fedora Source code.
I.E. all 2 billion lines, 11K packages, 132 GB of it.

For details including search syntax, please see:


I managed to copy&paste a UTF8 BOM onto the end of the previous URL.
Not sure how that happened, but anyway hopefully you can now click through:

http://www.pixelbeat.org/docs/fedora_source.html

thanks,
Pádraig.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

New Online search for the Fedora Source

[Pádraig Brady]

Benjamin Boyter has recently indexed the entire Fedora Source code.
I.E. all 2 billion lines, 11K packages, 132 GB of it.

For details including search syntax, please see:
http://www.pixelbeat.org/docs/fedora_source.html

thanks,
Pádraig.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: raising warning flag on firewalld-default feature

[Pádraig Brady]

On 11/12/2012 07:53 PM, Matthew Miller wrote:

On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote:

I really don't understand why a core system component such as firewalld is
implemented in Python!


Here, I mostly don't see the reason for it to be running all the time.
Couldn't it be dbus activated, and then go away when it's not needed? Then,
it would matter less what it was written in.


It could be argued that python is more suited to long lived programs:

$ time /bin/true
real0m0.002s
$ time python -c True
real0m0.049s
$ time python3 -c True
real0m0.165s

> And for reducing space use: I think it might also be nice to break python
> 2to3 and idle out of the python-libs package.

splitting python-libs (25MB here), seems worthwhile.
python-libs can bb changed to a subpackage that just depends on
various split subpackages, and then as needed various packages
like yum etc. can adjust dependencies to require just the
subpackages they need.

I remember doing a dist of python for an embedded system
that was 2.1MB in total and was enough to support cherrypy.

cheers,
Pádraig.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

[Pádraig Brady]

On 05/31/2012 11:45 AM, Pádraig Brady wrote:

On 05/31/2012 08:14 AM, Roberto Ragusa wrote:

On 05/31/2012 02:40 AM, Lennart Poettering wrote:

Heya!

Please be aware that since the most recent systemd uploads /tmp is now
in tmpfs by default in Rawhide/F18.

[...]

This will most likely lead to a problem or two with software that isn't
happy about /tmp being small.


For example "sort".


This is a good example because `sort` algorithmically needs
something below RAM in the memory hierarchy (i.e. bigger),
but with the same persistence characteristics of /tmp.

Currently `sort` defaults to $TMPDIR or if not set '/tmp'.

Now /var/tmp should be "more persistent" which we don't need,
but shouldn't be an issue, but should also not be in RAM
and so is more appropriate.


One possible issue is that stale sort tmp files could persist
in /var/tmp for 30 days even after a reboot.

I'm going to err on the side of leaving sort(1) as is
and using /tmp by default, as detailed at:
http://lists.gnu.org/archive/html/coreutils/2012-09/msg00139.html

In summary, sort(1) only needs stateless storage,
so lets keep it more abstract and default to /tmp,
rather than worrying about system specifics.

cheers,
Pádraig.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: small tip regarding git branch bash prompt in F18/Rawhide

[Pádraig Brady]

On 08/23/2012 12:12 AM, Adam Williamson wrote:
> Hey folks - just in case you haven't all figured this out yet, if you're 
> using the neat little trick of putting a few lines in your ~/.bashrc so that 
> when you're in a directory containing a git repo, the prompt will display 
> what branch you're in, it'll stop working when you update to the latest git - 
> 1.7.12 - in F18 or Rawhide. To fix it, you need to change:
> 
> source /etc/bash_completion.d/git
> 
> to:
> 
> source /usr/share/doc/git-1.7.12/contrib/completion/git-prompt.sh
> 
> because upstream split the prompt stuff out from the bash_completion script. 
> Perhaps the git packagers could consider providing git-prompt.sh in a more 
> permanent location, so we don't have to poke .bashrc every time the git 
> version changes? Thanks!

Nice one.
I've adjusted my .bashrc as follows,
which should work for all versions:

# show extra info in the prompt in git repos
git_prompt_dir=/usr/share/doc/git-*/contrib/completion
git_integration=$git_prompt_dir/git-prompt.sh
test -e $git_integration || git_integration=$git_prompt_dir/git-completion.bash
if test -e $git_integration; then
  source $git_integration
  export GIT_PS1_SHOWDIRTYSTATE=1
  PS1='\[\e[1m\]\h:\W$(__git_ps1 " (%s)")\$\[\e[0m\] '
fi

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Mass rebuild for Fedora 18 Complete

[Pádraig Brady]

On 07/22/2012 09:21 PM, Kevin Fenzi wrote:
> On Tue, 17 Jul 2012 07:39:31 -0500
> Dennis Gilmore  wrote:
> 
>> it was requested in https://fedorahosted.org/rel-eng/ticket/5222 that
>> we do a mass rebuild for Fedora 18 for
>> https://fedoraproject.org/wiki/Features/DwarfCompressor and
>> https://fedoraproject.org/wiki/Features/MiniDebugInfo due to a mix up
>> in dates it was going to start on 2012-07-30 but since that only gives
>> a week to do the rebuild before branching for f18 on 2012-08-07 we
>> will be starting the mass rebuild on 2012-07-18 
>>
>> This is a heads up that it will be done in a side tag and moved over
>> when completed. We will be running scripts to output failure stats.
>> please be sure to let releng know if you see any bugs in the
>> reporting.
> 
> The mass rebuild has completed and been tagged back into rawhide, they
> should appear in tomorrow's rawhide compose. 
> 
> 11057 packages were successfully rebuilt. 
> 656 packages failed to rebuild. 
> 
> Please fix any packages you maintain that failed to rebuild. 

I've fixed and rebuilt

python-sqlalchemy0.7

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Couldn't we enable 256 colors by default on TERM?

[Pádraig Brady]

On 06/26/2012 07:35 PM, Chris Adams wrote:
> Once upon a time, Miloslav Trmač  said:
>> Another one is that connecting to systems that don't support xterm-256
>> is not quite easy.  In particular, there appears to be no way to
>> configure ~/.ssh/config so that "ssh oldhost" (and "ssh oldhost
>> arbitrarycommand") transparently changes the TERM value - one would
>> have to set up shell functions or something similar.  An extension of
>> the ssh would be very nice - and failing that, an explicit recipe how
>> to override TERM correctly would be welcome as well.
> 
> The OpenSSH devs might be open to such.  I'd be willing to take it up
> with them and write a patch (if they'll accept it).
> 
> Any suggestions on how it should work?  Ideally, some way to say "drop
> the -256color suffix from TERM if preset" would be best.

Well this is a general issue.
For example with urxvt we have:

$ echo $TERM $COLORTERM
rxvt-unicode rxvt-xpm

So sshing from urxvt already needs resetting of $TERM on various systems.

I guess this issue might be some of the reason for the reluctance to address:
https://bugzilla.redhat.com/show_bug.cgi?id=230682

The usual way to set/adjust TERM appropriate for the remote system
is just to use the startup files there. This is what I add to ~/.profile
on a solaris system for example:

[ "$SSH_CONNECTION" ] && export TERM=xterm

I'm not sure adding such functionality to .ssh/config
would be of much benefit TBH.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Couldn't we enable 256 colors by default on TERM?

[Pádraig Brady]

On 06/26/2012 02:37 PM, Thomas Moschny wrote:
> 2012/6/26 Chris Adams :
>> The newer terminal
>> programs have configuration menus for various things; do any of them set
>> it there?  If they don't, I would think it would be relatively easy to
>> add (and hopefully upstreams would accept such patches).
> 
> Tried with XFCE's "Terminal", which has a $TERM option in its
> configuration dialog (under advanced options), but it simply doesn't
> work. I set it to "xterm-256color", but within the shell, TERM is
> still "xterm".
> 
> Not sure whether that is an XFCE (or vte) bug, or whether some
> system-wide profile script overrides it. Afaict, none of my user
> profile scripts overrides it.

See bottom comment here:
https://bugs.archlinux.org/task/21007#comment94595
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Couldn't we enable 256 colors by default on TERM?

[Pádraig Brady]

On 06/26/2012 03:56 AM, Chris Adams wrote:
> Once upon a time, Matthew Garrett  said:
>> On Mon, Jun 25, 2012 at 08:47:16PM -0500, Chris Adams wrote:
>>> Trying to do this in profile scripts assumes that you only run local
>>> terminals that come from Fedora and that have been tested.  For example,
>>> if you SSH to a Fedora box from an old xterm that doesn't do 256 colors,
>>> what happens if profile automagically turns xterm into xterm-256color?
>>
>> The proposal actually handles that by parsing the output of the who 
>> command, but I'm not sure I'm morally in favour of that.
> 
> That wasn't there when I checked before my email, so I didn't know that.
> It sounds like adding one hack on top of another; trying to parse the
> output of a command not documented to have a fixed specific format is an
> even worse idea IMHO.

Fair enough.

The main caveat with per terminal settings is that
it might be desired to provide config options per terminal.
Though I suppose users can always override TERM in their
startup files in the unlikely case they need to change
back to 'xterm' for example.

Note the feature is not completed at all.
The presented /etc/profile.d/256colors.sh was only
a 2 minute hack that I thought was worth presenting
as it allows one to easily check the feature and
it does actually work in the vast majority of cases.

> I'm also always looking to avoid having more programs automatically run
> at the start of a login.  If you've ever had to deal with logging into
> an overloaded system, the last thing you want is a profile script doing
> "who" and "grep" just to try to override the TERM variable to make it
> prettier.  I'd like to see less of that, not more.

Agreed.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

[Pádraig Brady]

On 06/01/2012 08:56 PM, Reindl Harald wrote:
> 
> 
> Am 01.06.2012 20:14, schrieb Simo Sorce:
>> On Fri, 2012-06-01 at 12:58 -0500, Chris Adams wrote:
>>> Once upon a time, Simo Sorce  said:
 On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
> Once upon a time, Reindl Harald  said:
>> thank you for breaking setups of well thought virtual machines
>> on expensive SAN storages with a as small as possible rootfs
>> with a own virtual disk for /tmp with new defaults
>
> If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and
> still work exactly as before (if not, that's a bug and should be treated
> as such).

 Chris, the problem is that now you have to add a /tmp filesystem,
 before /tmp was just a normal directory in root.
>>>
>>> Did you read what I was replying to?  My understanding of it was about
>>> already using a separate /tmp filesystem.
>>
>> I read it but I have misunderstood. I would hope people that already
>> have /tmp in fstab see no changes.
> 
> but they do and this is was Chris Adams do not understand because he only
> reads what he has quoted and not what was the reason for my reply which
> gives "Did you read what I was replying to" a special taste
> 
> patching applications for "/var/tmp rather than /tmp" is a real problem
> for people which are smart enough to know  why they introduced a seperated
> disk for /tmp
> 
> this changes means that the crap no longer goes to /tmp and will hit in
> the future rootfs because switch to /var/tmp
> ___
> 
> HERE AGAIN THE FULL QUTOE TO GET BACK CONTEXT!
> 
>>> So I'll patch sort to default to /var/tmp rather than /tmp
>> thank you for breaking setups of well thought virtual machines
>> on expensive SAN storages with a as small as possible rootfs
>> with a own virtual disk for /tmp with new defaults

So what if _existing_ systems write to /var/tmp in the above setup?
/var/tmp is there already so it needs to be handled.
Seems like you should link /var/tmp to /tmp to handle that.
And/Or you should probably set TMPDIR=/tmp system wide to enforce
this non standard setup.

If you do that, then as well as closing the existing loophole,
you make the system immune to future changes in this area
as apps should honor $TMPDIR before using their defaults of
/var/tmp or /tmp or /whatever

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Action required: Rawhide: /tmp is now on tmpfs

[Pádraig Brady]

On 06/01/2012 02:47 PM, Ralf Corsepius wrote:
> On 06/01/2012 02:12 PM, Alexey I. Froloff wrote:
>> On Fri, Jun 01, 2012 at 01:21:25PM +0200, Miloslav Trmač wrote:
>>> Therefore, it is reasonable to assume that Fedora 18 will ship with
> I certainly disagree ... this change is not reasonable.
> 
>>> this change, and applications need to be updated to handle the change,
>>> or we will have a more broken Fedora 18.  Advising people not to patch
>>> programs won't make Fedora 18 less broken at this point.
>> I was using /tmp on tmpfs (with $TMPDIR poining inside of /tmp)
>> for several years in ALT Linux.  And by "use" I mean "build
>> packages using mock-like tool that creates chroots in $TMPDIR".
>> During all these years, my biggest problem was that tmpfs by
>> default allocates half of physical RAM for partition.  So I just
>> allocated big enough swap and added a line to /etc/fstab with
>> appropriate size= option.
>>
>> Having /tmp on tmpfs is not THAT scary, is you ask me...
> 
> If you ask me (I did the same for some time (Fedora 13-14 era) ) the typical 
> symptoms of /tmp on tmpfs are sporatic, non-deterministic malfunctions.
> 
> I guess is, struggling with these sporadic malfunction will become an FAQ.
> 
> 
> Finally, using /var/tmp instead of /tmp for temporary files (c.f. the "sort" 
> case in another thread) contradicts the primary purpose of /tmp on tmpfs: 
> *speed*
> 
> In other words, moving current /tmp use-cases to /var/tmp will not gain you 
> any speed-wise.

Not all /tmp user-cases need to move to /var/tmp

sort is special in this regard in that it only uses
external files when there isn't enough RAM.
I.E. is expects it to be slower (larger).

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

[Pádraig Brady]

On 06/01/2012 12:15 AM, Sergio Durigan Junior wrote:
> On Thursday, May 31 2012, Ralf Corsepius wrote:
> 
>> On 05/31/2012 12:45 PM, Pádraig Brady wrote:
>>> On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
> 
>>> Now /var/tmp should be "more persistent" which we don't need,
>> Correct, using /var/tmp is wrong and a mistake.
>>
>> IMO, advising people to modify their code to using /var/tmp instead of
>> /tmp is absurd and evidence of ignorance towards traditional use of
>> /tmp and the FHS.
> 
> I couldn't say better.
> 
>>> So I'll patch sort to default to /var/tmp rather than /tmp.
> 
> Please don't.  As many pointed out, there are many disadvantages in
> doing this, and I really do not think we should be "fixing" (sic) our
> apps because of such a controversial feature.  `sort' and other programs
> have been working right like this for *years*; introducing such change
> would mean "please give me more bugs", as Ralf pointed out.

Well Ralf didn't impart any info as to why moving to /var/tmp would be a bug.
If it's a symlink to /tmp on older systems then there is no change.
But if the system /tmp is tmpfs then it would be a bug not to change,
which is the new default on debian IIUC.
BTW there is a long recent thread debian thread about the issues:
http://lists.debian.org/debian-devel/2012/05/thrd3.html#01092

The main issue I see at the moment is that apps have
overloaded /tmp for different things and it will
take time to tease these things out.

Don't worry I'm not going to jump to anything rashly,
but `sort` needs to spool to non RAM, so we'll have to
adjust if /tmp is RAM.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Couldn't we enable 256 colors by default on TERM?

[Pádraig Brady]

On 05/31/2012 11:09 AM, Marc Deop i Argemí wrote:
> On Thursday 31 May 2012 02:20:26 Pádraig Brady wrote:
>> On 05/30/2012 04:16 PM, Marc Deop wrote:
>>> On Wednesday 30 May 2012 10:04:49 Pádraig Brady wrote:
>>>> I've some notes about 256 colors here:
>>>> http://www.pixelbeat.org/docs/terminal_colours/#256
>>>>
>>>
>>> That information is mostly fine. There are some errors though (you say you 
>>> set your TERM variable in your .bashrc...)
>>
>> Yes. If you follow the link to my .bashrc it further clarifies that
>> to handle all cases, the variable should be set earlier in ~/.profile
>> or system wide in /etc/profile.d/...
>>
> 
> Still wrong in my opinion. This should be set by your terminal emulator (be 
> it konsole, gnome-terminal or whatever) and not in your personal environment. 
> You would end up having to check for *a lot* of things

I'm leaning towards needing the configurability of a /etc/profile.d/256color.sh 
file.
That could be a central config point and support various required TERM and 
TERMCAP tweaks.

>>>> If you restrict yourself to local xterms
>>>> (of most varieties) you're fine.
>>>>
>>>
>>> Nowadays you'll be fine almost everywhere. Your system should not set the 
>>> TERM variable to "xterm" or whatever if you are in a virtual terminal (that 
>>> would happen if you set your TERM variable in your .bashrc for example...)
>>
>> Well that also happens if set in /etc/profile etc.
>> What you need to do I think is guard like:
>>
>> $ cat /etc/profile.d/256color.sh
>> [ "$TERM" = 'xterm' ] && TERM=xterm-256color; export TERM
> 
> What happens with "urxvt" or "eterm" terminals?
> 
> As said above, .profile or .bashrc or whatever is not a good place to set 
> this things
> 
>>
>>>
>>>> However...
>>>>
>>>> 256 color doesn't work correctly on Linux virtual consoles.
>>>>
>>>
>>> Totally true
>>
>> Handled with the conditional above
> 
> That works for VT that use xterm as TERM environment but... what of other 
> ones?

So why do they have separate TERM than 'xterm';
do they have separate facilities they want to distinguish?
I tried urxvt there and it sets TERM=rxvt-unicode
I notice that vim at least recognizes this as 256 color already.

Note 'rxvt-unicode' has the same issue when I ssh to solaris:

$ man ls
WARNING: terminal is not fully functional
/tmp/blahblah (press RETURN)

If the minority of xterms want to set their own TERM value,
then we shouldn't worry about it I think, as those values
will have to be dealt specifically by apps/systems anyway.

By mapping xterm to xterm-256color we catch most terminals,
and hopefully there are none of those that don't support 256 colors.
Any that don't could be excluded anyway.

>>>> Also since your $TERM is propagated to remote systems
>>>> when you ssh, if they don't support that you'll have issues.
>>>> For example sshing to debian systems (I've not tried newer releases)
>>>> will be problematic unless a package in installed there.
>>>> Also if I ssh to solaris then I need to reset TERM to "xterm"
>>>> for man pages to work correctly etc.
>>>
>>> IMHO this should be the other way around: for old systems where the 256 
>>> don't work you should manually set your TERM variable to something that 
>>> would work and not the other way around
>>
>> This could be contentious.
>>
>> However I notice (from searching the web) is that Mac OS X
>> Terminal's default $TERM value is xterm-256color since Lion 10.7.
>>
>> What I'd do (I will do if you prefer) is to propose the feature at:
>> https://fedoraproject.org/wiki/Releases/18/FeatureList
>> That will both provide a todo list and allow voting on acceptance.
>>
> 
> That sounds reasonable, +1 for me here! :)

I'll let Kévin do this as it was his initiative.
I'll help out wherever is needed.

>> Also in the release notes we should have notes for workarounds
>> for older systems where you would have issues.
>> I notice ncurses-term is still 'standard' rather than 'required' in debian.
>> Perhaps we could log a request for that to change?
>> Note that package is 6.6MB installed so maybe the 256 color support
>> could be merged back to ncurses-base ?
>>
>> I just tried ubuntu 12.04 there and it also doesn't install ncurses-term.
>> I did the

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

[Pádraig Brady]

On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
> On 05/31/2012 02:40 AM, Lennart Poettering wrote:
>> Heya!
>>
>> Please be aware that since the most recent systemd uploads /tmp is now
>> in tmpfs by default in Rawhide/F18.
> [...]
>> This will most likely lead to a problem or two with software that isn't
>> happy about /tmp being small.
> 
> For example "sort".

This is a good example because `sort` algorithmically needs
something below RAM in the memory hierarchy (i.e. bigger),
but with the same persistence characteristics of /tmp.

Currently `sort` defaults to $TMPDIR or if not set '/tmp'.

Now /var/tmp should be "more persistent" which we don't need,
but shouldn't be an issue, but should also not be in RAM
and so is more appropriate.

So I'll patch sort to default to /var/tmp rather than /tmp.

I'm a little worried about the general availability of /var/tmp.
I know I've created distros without it at least.

For my own reference, sort does support a list of tmp dirs,
but it'll need to be tweaked to support non existent dirs:

  $ seq 10 | sort -T /foo -T /tmp -S1M
  sort: cannot create temporary file in `/foo': No such file or directory

`tac` from coreutils also needs a similar patch.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Couldn't we enable 256 colors by default on TERM?

[Pádraig Brady]

On 05/30/2012 04:16 PM, Marc Deop wrote:
> On Wednesday 30 May 2012 10:04:49 Pádraig Brady wrote:
>> I've some notes about 256 colors here:
>> http://www.pixelbeat.org/docs/terminal_colours/#256
>>
> 
> That information is mostly fine. There are some errors though (you say you 
> set your TERM variable in your .bashrc...)

Yes. If you follow the link to my .bashrc it further clarifies that
to handle all cases, the variable should be set earlier in ~/.profile
or system wide in /etc/profile.d/...

>> If you restrict yourself to local xterms
>> (of most varieties) you're fine.
>>
> 
> Nowadays you'll be fine almost everywhere. Your system should not set the 
> TERM variable to "xterm" or whatever if you are in a virtual terminal (that 
> would happen if you set your TERM variable in your .bashrc for example...)

Well that also happens if set in /etc/profile etc.
What you need to do I think is guard like:

$ cat /etc/profile.d/256color.sh
[ "$TERM" = 'xterm' ] && TERM=xterm-256color; export TERM

> 
>> However...
>>
>> 256 color doesn't work correctly on Linux virtual consoles.
>>
> 
> Totally true

Handled with the conditional above

>> Also since your $TERM is propagated to remote systems
>> when you ssh, if they don't support that you'll have issues.
>> For example sshing to debian systems (I've not tried newer releases)
>> will be problematic unless a package in installed there.
>> Also if I ssh to solaris then I need to reset TERM to "xterm"
>> for man pages to work correctly etc.
> 
> IMHO this should be the other way around: for old systems where the 256 don't 
> work you should manually set your TERM variable to something that would work 
> and not the other way around

This could be contentious.

However I notice (from searching the web) is that Mac OS X
Terminal's default $TERM value is xterm-256color since Lion 10.7.

What I'd do (I will do if you prefer) is to propose the feature at:
https://fedoraproject.org/wiki/Releases/18/FeatureList
That will both provide a todo list and allow voting on acceptance.

Also in the release notes we should have notes for workarounds
for older systems where you would have issues.
I notice ncurses-term is still 'standard' rather than 'required' in debian.
Perhaps we could log a request for that to change?
Note that package is 6.6MB installed so maybe the 256 color support
could be merged back to ncurses-base ?

I just tried ubuntu 12.04 there and it also doesn't install ncurses-term.
I did the following to double check:
  $ TERM=xterm-256colors man ls
  WARNING: terminal is not fully functional

>> So it's one of those borderline things that is unfortunately
>> dependent on the users environment, so I'd be wary about
>> changing this default.
> 
> I see no problem in setting the gnome-terminal (or konsole or whatever) to 
> use 256 by default in a bleeding edge distro like Fedora. Again, we should 
> change this settings when they do not work ;)

There is still further issues to consider locally.
screen and vim settings would need to be tweaked also as per:
http://www.robmeerman.co.uk/unix/256colours

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Couldn't we enable 256 colors by default on TERM?

[Pádraig Brady]

On 05/30/2012 09:30 AM, Kévin Raymond wrote:
> Hi there,
> 
> We are building a leading edge Operating System, but still use only 8bit 
> colors
> by default in our terminal (I don't know about KDE… I stay under
> GNOME, gnome-term (xterm)).
> This limit the colors of many applications like vim, screen, tmux, weechat…
> 
> As seen (quick but not exhaustive check), all dependencies for xterm
> in 256 colors are there,
> we just need to define `TERM=xterm-256color' in order to get 256 colors…
> 
> So what would be needed?

I've some notes about 256 colors here:
http://www.pixelbeat.org/docs/terminal_colours/#256

If you restrict yourself to local xterms
(of most varieties) you're fine.

However...

256 color doesn't work correctly on Linux virtual consoles.

Also since your $TERM is propagated to remote systems
when you ssh, if they don't support that you'll have issues.
For example sshing to debian systems (I've not tried newer releases)
will be problematic unless a package in installed there.
Also if I ssh to solaris then I need to reset TERM to "xterm"
for man pages to work correctly etc.

So it's one of those borderline things that is unfortunately
dependent on the users environment, so I'd be wary about
changing this default.

cheers,
Pádraig.

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

Re: Total size of Fedora source

[Pádraig Brady]

On 05/18/2012 02:17 PM, Alek Paunov wrote:
> Hi Rich,
> 
> On 18.05.2012 15:49, Richard W.M. Jones wrote:
>> The reason is that I want to check out all the source for an
>> experiment, and I need to know what order of disk space I will need [:-)]
> 
> Would you like to elaborate - What kind of experiment you are preparing?
> 
> [Asking because I live with the idea about Fxx-snapshot mass source 
> indexing/XRref for long time already (based mainly on the great David 
> Malcolm's gcc-python-plugin, the openjdk compiler and several other tools) 
> and if your work will be in the same direction I am willing to take part of 
> the tasks - e.g. DBs related work ...]

An online equivalent to http://livegrep.com/ would rock :)

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Total size of Fedora source

[Pádraig Brady]

On 05/18/2012 01:49 PM, Richard W.M. Jones wrote:
> Does anyone have an estimate for the total size of the checked out and
> "prepped" source code (w/o binaries) in Fedora (eg. in F17)?
> 
> The reason is that I want to check out all the source for an
> experiment, and I need to know what order of disk space I will need [:-)]
> 
> Rich.
> 

Dave Jones did that recently:
http://codemonkey.org.uk/2012/02/24/fedora-master-branch-statistics/

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Please add GNU id-utils to Fedora

[Pádraig Brady]

On 05/11/2012 09:14 AM, Jim Meyering wrote:
> Miloslav Trmač wrote:
>> On Thu, May 10, 2012 at 9:49 PM, Greg McGary  wrote:
>>> Minor conflict: the name of one of id-utils main commands "lid" is also the
>>> same as an existing command, though installed in a different place.  
>>> id-utils
>>> has /usr/bin/lid, while libuser has /usr/sbin/lid.
>>
>> Yeah, that's come up before.  There's no great solution I'm afraid,
>> one or the other will have to change
> 
> Technically there is no need to change a name.
> In Debian, one can have two lid programs installed, one in /usr/bin
> and the other in /usr/sbin[*], so why not in Fedora?
> 
> Sure, a different solution would be better, but renaming a command like
> idutils' lid (in use by some for >15 years) does not seem reasonable.
> 
> Any opinions on whether this issue is big enough to NAK
> a review request or addition of the package to Fedora?

Well /usr/sbin is proposed to be merged with /usr/bin in Fedora 18

Anyway I think having the same name in different paths is too problematic.

id-utils (1996) seems to predate libuser (2001), so it's
unfortunate that libuser picked the clashing name.

I'm not sure what to suggest though.
The simplest is to rename the id-utils lid on fedora,
which will not break anything, but does introduce awkwardness
in future script portability, needing something like:
  lid-utils > /dev/null && LID=lid-utils || LID=lid
/etc/alternatives probably isn't appropriate as I'm
assuming the commands do not overlap in functionality.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Install Fedora Button for LiveCD

[Pádraig Brady]

On 05/02/2012 08:47 PM, Kalev Lember wrote:
> On 05/01/2012 07:25 PM, Jared K. Smith wrote:
>> I've got to be honest here -- I don't like the wording of the
>> notification. /.../
> 
> Pádraig, Jared, Chris:
> 
> Thanks for the suggestions
> 

> How about this as the main text:

> You are currently running Fedora from live media.
> If you are ready, you can install Fedora now, or choose "Install to Hard
> Drive" in the Activities overview at any later time.

"If you are ready" is a bit redundant. How about.

You are currently running Fedora from live media.
You can install Fedora now, or choose "Install to Hard
Drive" in the Activities overview at any later time.

I'm happy with any of the subsequent suggestions,
so feel free to commit without further input from me anyway.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Install Fedora Button for LiveCD

[Pádraig Brady]

On 05/01/2012 02:55 PM, Kalev Lember wrote:
> On 04/28/2012 12:33 AM, Jared K. Smith wrote:
>> On Fri, Apr 27, 2012 at 3:02 PM, Bill Nottingham  wrote:
>>> I don't know how proposing and implementing a notification method of doing
>>> the same isn't providing a solution, but you're welcome to your own cross.
>>
>> Sorry Bill -- I'm confused here.  Was a notification method actually
>> implemented?  Was it enabled in F17.TC1?  If so, I didn't see it.  Or
>> was it implemented only for rawhide?
> 
> I finished up the work on the notification and landed it in
> spin-kickstarts, so it should be available with the next media compose
> for both F17 and rawhide:
> 
> http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=commit;h=ef24d01
> 
> This is how it currently looks after booting up the Desktop Live CD:
> http://kalev.fedorapeople.org/anaconda-notification.png
> 
> "Install" starts the installer; clicking anywhere else within the black
> notification box dismisses the notification.

Excellent thanks!

A slight rewording suggestion, especially since "hard disks"
are being rapidly replaced.

"You are currently using an uninstalled live image.
You can try it out directly or install to your system."

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review swaps

[Pádraig Brady]

Hi!

I've a simple new package containing some
support scripts for the OpenStack packages:
https://bugzilla.redhat.com/show_bug.cgi?id=811601

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Install Fedora Button for LiveCD

[Pádraig Brady]

On 04/03/2012 02:26 PM, Kamil Paral wrote:
> I was quite depressed how hard it can be for a layman to find a way to 
> install Fedora from LiveCD environment.

On a more general note it would be nice to stream-line the experience from web 
to installation.
Most of the hard parts are done, just a few steps to polish.

As a developer I don't read the docs and for ages have just:

wget -c ... # download live image (-c to resume partial)
ls -1 /sys/block | grep usb (To find USBDEV)
dd iflag=direct oflag=direct bs=1M if=file.iso of=/dev/$USBDEV
 (I use direct to avoid linux virtual memory stalls and cache eviction)

So as an experiment I tried as a new user would,
to see how easily they could come to an equivalent conclusion:

1a. Search for "install fedora" -> get.fedoraproject.org
 This is very good
1b. Search for "fedora linux" -> fedoraproject.org
 This is OK, but there are 6 download links on that page which is confusing.
 Also it mentions "CD-ROM" image which is no longer the norm.
 I'd just have "download development" linking to iso, and "download" linking to 
get.fedoraproject.org

2. To get to the default instructions for writing the image:
  http://fedoraproject.org/en/get-fedora (alias for get.fedoraproject.org)

http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Making_USB_Media.html
 (covers windows)
  
http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Making_USB_Media-UNIX_Linux.html
3.2.2.1.1. Making Fedora USB Media with a graphical tool
  This erroneously mentions needing to enable EPEL.
  I also notice this pulls in lots of QT stuff to a default install 
(106MB!)
  So I insert my (existing F17) usb install disk and
  run the liveusb-creator GUI which outputs
Unable to find any USB drives
Enabling -v from the command line, gives:
  Skipping /dev/sdb with unknown filesystem: iso9660
  So apparently this tool is a higher level tool and doesn't support a mode
  where the image is simply written to the device.

I'll look at improving the Fedora docs as per the notes above.

> If you don't recognize the icon in Gnome Shell Overview mode, it can give you 
> quite some work to find it.

To be precise, one has to:
 1. Click activities
 2. Click the hard drive "with a green hat on it"
I agree that's not immediately obvious.
So as to solutions:
1. Your suggestion of a persistent panel item is not ideal but better.
This is a fine interim solution.
2. The suggestion of an earlier "install" or "boot live" option is good too, 
but a bit more invasive.
3. The suggestion of using notifications may be better but not until 
notifications are fixed:
http://www.youtube.com/watch?v=14z4wdgNF9g

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora Packages Search

[Pádraig Brady]

On 03/30/2012 08:43 AM, "Jóhann B. Guðmundsson" wrote:
> On 03/30/2012 07:06 AM, Johannes Lips wrote:
>> Hi all,
>>
>> I really like this website[1] and think it's really useful. I just wanted to 
>> know what the current state of it is
> 
> 
> There are two things I feel need improvements one is the bug section of it, 
> with my QA hat on I would rather like to see monthly/weekly/daily line or bar 
> graph activity on bugstats instead of what's currently there.
> 
> In the source section I would like to see a git links and link to the 
> upstream source.

Right. That's in the plan:
https://fedoraproject.org/wiki/Fedora_Packager

> Other then the above mentioned items it's becoming very useful and part of my 
> workflow within the project.

+1 to that. I especially like the search feature which
I can use to summarize the openstack projects for example:
https://community.dev.fedoraproject.org/packages/s/openstack
Though being able to tag and search on tags would be more general.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: urandom vs haveged

[Pádraig Brady]

On 03/26/2012 11:55 PM, Chris Murphy wrote:
> 
> 
> On Mar 26, 2012, at 4:31 PM, Pádraig Brady wrote:
>>
>> Well if you're just writing huge amounts of "random" data
>> to clear existing space, then you don't need it to be cryptographically 
>> secure.
>> Why are you doing this exactly? Would /dev/zero suffice?
> 
> In every supposed best practice case of dm-crypt LUKS setup, urandom is used 
> by example. Including by Red Hat and Fedora Projects. The Fedora link says: 
> "You're looking at a process that takes many hours, but it is imperative to 
> do this in order to have good protection against break-in attempts. Just let 
> it run overnight."
> 
> http://www.redhat.com/summit/2011/presentations/summit/taste_of_training/wednesday/Strickland_On_Disk_Encryption_with_RHEL.pdf
> 
> http://fedoraproject.org/wiki/Implementing_LUKS_Disk_Encryption
> 
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption-Manually_Encrypting_Directories-Step_by_Step_Instructions.html
> 
> So then the question is, if urandom is what's recommended, are faster 
> substitutes just as good? If they are just as good, then why aren't they the 
> first recommendation? And if this step is superfluous, then I'd suggest 
> documentation be changed to eliminate the suggestion altogether.

Well I can only think of two reasons for writing "random" data.
1. Ensure all existing data is overwritten (zeros would do just as well on 
modern drives)
2. Homogenize written (with luks data) and nonwritten parts of the drive,
so that you can't determine the extent of the real encrypted data.

I think `shred -v -n1 /your/device` is fine for this:
http://burtleburtle.net/bob/rand/isaacafa.html

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: urandom vs haveged

[Pádraig Brady]

On 03/26/2012 08:56 PM, Chris Murphy wrote:
> 
> Performance:
> 
> dd if=/dev/zero   ~56MB/s CPU < 10%
> dd if=/dev/urandom~12MB/s CPU 99%
> haveged   ~54MB/s CPU < 25%
> 
> 
> The dd relative values are consistent with kernels in Fedora 16. However 
> these tests were done with 3.3.0-1. The questions are:
> 
> Is the urandom performance expected?
> 
> What is the quality of pseudo-random data produced by urandom vs haveged?
> 
> If the qualities are similar, or haveged's is better, is there anything that 
> can be done to improve urandom's performance? It really takes quite a bit 
> longer to prepare a disk/volume for encryption.

Well if you're just writing huge amounts of "random" data
to clear existing space, then you don't need it to be cryptographically secure.
Why are you doing this exactly? Would /dev/zero suffice?
In any case it seems you could use shred rather than dd to clear data?
It has been changed to use a much faster internal generator:

http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=v7.2-21-gaf5723c

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /etc/default in Fedora

[Pádraig Brady]

On 03/06/2012 04:21 PM, Daniel J Walsh wrote:
> On 03/05/2012 03:20 PM, Michał Piotrowski wrote:
>> Hi,
> 
>> I wanted to add "selinux=0" to the kernel command line on F17. I 
>> checked /etc/sysconfig/, /etc/grub.d/, next I started to read 
>> /etc/grub.d/10_linux (this new grub2 is so user friendly..) and I 
>> found ${GRUB_CMDLINE_LINUX}. So I grepped /etc for
>> GRUB_CMDLINE_LINUX. I found file: /etc/default/grub
> 
>> Why /etc/default dir is used instead of /etc/sysconfig? To be
>> honest - it's not really user friendly from long time RH Linux user
>> POV.
> 
> Just disable SELinux in /etc/selinux/config.

There are subtle differences with doing that apparently.
http://lists.gnu.org/archive/html/coreutils/2012-02/msg00176.html

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GPT and Fedora 17

[Pádraig Brady]

On 03/02/2012 07:09 PM, Chris Murphy wrote:
> 
> On Mar 2, 2012, at 10:37 AM, Pádraig Brady wrote:
> 
>> Yep as expected F17 alpha is broken in the same way on my laptop.
> 
> Your laptop is what hardware? Any install media kernel parameters used? What 
> installation type? Can you provide both an fdisk and parted (or gdisk) 
> listing of the post-installation disk?

For earlier in the thread:

"Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29,
and it didn't help.  I.E. point (1.) from the link referenced here:
https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31";
You can see the boot flag is set to no avail in the disk
and parted output below:

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x

   Device Boot  Start End  Blocks   Id  System
/dev/sda1   *   1   976773167   488386583+  ee  GPT


Model: ATA ST9500420AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start   End SizeFile system  Name  Flags
 1  1049kB  2097kB  1049kB bios_grub
 2  2097kB  526MB   524MB   ext4 ext4  boot
 3  526MB   500GB   500GB  lvm

I've confirmed that installing with the "nogpt" flag is OK.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GPT and Fedora 17

[Pádraig Brady]

On 02/07/2012 12:54 AM, Adam Williamson wrote:
> On Mon, 2012-02-06 at 23:19 +0000, Pádraig Brady wrote:
>> On 02/06/2012 10:40 PM, Brian C. Lane wrote:
>>> In Fedora 16 we changed to using GPT as the default disklabel for new
>>> installs. In a few cases, mostly limited to Lenovo hardware, we found
>>> that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling
>>> back to msdos labels in order to solve this.
>>>
>>> Thanks to Matthew Garrett we found that switching on the boot flag of
>>> the GPT's protective MBR these BIOS's would then boot from GPT. Matthew
>>> wrote a patch for parted to allow controlling this flag using the
>>> disk_set pmbr_boot command in parted. This is in parted-3.0-7
>>>
>>> In anaconda-17.6 I have reverted the Lenovo blacklist and changed things
>>> so that pmbr_boot is always set on GPT labeled installs. This should
>>> ensure that thing boot correctly.
>>>
>>> If this still causes problems the symptom will be that grub never starts
>>> and the bios may complain about not being able to find an OS. If you
>>> have problems with this please open a bug with the output from dmidecode
>>>
>>> You can still force usage of msdos partitions by passing nogpt on the
>>> kernel cmdline.
>>
>> Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29,
>> and it didn't help.  I.E. point (1.) from the link referenced here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31
>>
>> Fingers crossed I just missed something at the time.
>> I'll try out again tomorrow maybe.
> 
> Yes, I remember that. Please do test the change out and let us know the
> results, we'd definitely like to know.

Yep as expected F17 alpha is broken in the same way on my laptop.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GPT and Fedora 17

[Pádraig Brady]

On 02/06/2012 10:40 PM, Brian C. Lane wrote:
> In Fedora 16 we changed to using GPT as the default disklabel for new
> installs. In a few cases, mostly limited to Lenovo hardware, we found
> that some BIOS's would not boot from GPT. We blacklisted Lenovo, falling
> back to msdos labels in order to solve this.
> 
> Thanks to Matthew Garrett we found that switching on the boot flag of
> the GPT's protective MBR these BIOS's would then boot from GPT. Matthew
> wrote a patch for parted to allow controlling this flag using the
> disk_set pmbr_boot command in parted. This is in parted-3.0-7
> 
> In anaconda-17.6 I have reverted the Lenovo blacklist and changed things
> so that pmbr_boot is always set on GPT labeled installs. This should
> ensure that thing boot correctly.
> 
> If this still causes problems the symptom will be that grub never starts
> and the bios may complain about not being able to find an OS. If you
> have problems with this please open a bug with the output from dmidecode
> 
> You can still force usage of msdos partitions by passing nogpt on the
> kernel cmdline.

Hmm, I tried that workaround I think on my Lenovo T520 with BIOS 1.29,
and it didn't help.  I.E. point (1.) from the link referenced here:
https://bugzilla.redhat.com/show_bug.cgi?id=735733#c31

Fingers crossed I just missed something at the time.
I'll try out again tomorrow maybe.

cheers,
Pádraig.

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

Re: Bad coding practices in Fedora packages

[Pádraig Brady]

On 01/03/2012 01:32 PM, Denys Vlasenko wrote:
> I installed F16 on a new machine, trying to keep the installation
> more or less lean. Meaning - not installing tons of packages w/o
> thinking and ending up with tons of installed stuff I don't even know
> what it is.
> 
> Today, I'm looking at my process list, sorted by amount of dirtied pages
> (which very closely matches amount of malloced and used space - that is,
> malloced, but not-written to memory areas are not included).
> This is the most expensive type of pages, they can't be discarded.
> If we would be in memory squeeze, kernel will have to swap them out,
> if swap exists, otherwise kernel can't do anything at all.
> 
> And this is what I see (DIRTY column):
> 
>   PID   VSZ VSZRW   RSS (SHR) DIRTY^(SHR) STACK COMMAND
>  1974  593m  392m  233m 14900  200m64   208 
> /usr/lib/thunderbird/thunderbird-bin
>  2030  589m  393m  188m 16568  156m   684   344 /usr/lib/firefox/firefox
>  1375 27976 14100 14288  5752  9912  3896   132 /usr/bin/Xorg
>  1888 71748 55152 14056  4268  9536 0   132 /usr/libexec/tracker-store
>  1953  145m 44672 17588  6812  888088   132 
> /usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin
>  2057  167m  9036 18944 10124  8236   280   204 xchat
>  4292 15728  8344 10236  1440  7848 0   132 /usr/bin/mc -u -d -C
>  1892 36464  7608 16396  7116  7296 0   136 {applet.py} /usr/bin/python 
> /usr/share/system-config-printer/applet.py
>  1874 48464 27060 12408  5568  6180 0   132 /usr/libexec/tracker-miner-fs
>  1941  107m 13872 14784  8968  5620   768   132 Terminal
>  1901 44748 26400 10872  5012  5560 0   132 
> /usr/libexec/tracker-miner-flickr
> ...
> 
> thunderbird, firefox, xorg are the largest ones, but this
> is not a surprise.
> 
> Whoops. What is tracker-store? I don't even know what's that
> and why is it running, and it's eating ~10 mbytes in DIRTY.
> Hmm. There are more of those things - tracker-miner-fs,
> tracker-miner-flickr. There go another 12 megs...
> And - flickr??
> I did not ask anything flickr-related to be *run* on my machine!

Just a comment on the accuracy of the numbers.

# ps_mem.py¹ | grep tracker

  3.2 MiB + 730.5 KiB =   3.9 MiB   tracker-miner-fs
  3.9 MiB + 722.5 KiB =   4.6 MiB   tracker-miner-flickr
  5.5 MiB + 549.0 KiB =   6.0 MiB   tracker-store

I've attached the complete output from my newly installed F16 laptop,
which shows around 300MiB of RAM being used in total.

cheers,
Pádraig.

¹ http://www.pixelbeat.org/scripts/ps_mem.py
 Private  +   Shared  =  RAM used   Program 

116.0 KiB +  17.0 KiB = 133.0 KiB   system-setup-keyboard [updated]
128.0 KiB +  22.0 KiB = 150.0 KiB   gnome-pty-helper.#prelink#.Lnb918 
[deleted]
152.0 KiB +  16.5 KiB = 168.5 KiB   fcoemon [updated]
196.0 KiB +  21.5 KiB = 217.5 KiB   mcelog [updated]
180.0 KiB +  39.0 KiB = 219.0 KiB   atd
240.0 KiB +  27.0 KiB = 267.0 KiB   audispd
228.0 KiB +  44.5 KiB = 272.5 KiB   systemd-stdout-syslog-bridge [updated]
204.0 KiB +  72.0 KiB = 276.0 KiB   abrtd [updated]
228.0 KiB +  48.0 KiB = 276.0 KiB   sedispatch [updated]
252.0 KiB +  49.0 KiB = 301.0 KiB   syndaemon [updated]
240.0 KiB +  63.5 KiB = 303.5 KiB   abrt-dump-oops [updated]
264.0 KiB +  41.0 KiB = 305.0 KiB   rtkit-daemon [updated]
272.0 KiB +  33.5 KiB = 305.5 KiB   dbus-launch [updated]
344.0 KiB +  43.5 KiB = 387.5 KiB   auditd
448.0 KiB +  66.0 KiB = 514.0 KiB   systemd-logind [updated]
436.0 KiB +  81.5 KiB = 517.5 KiB   lldpad
452.0 KiB +  72.5 KiB = 524.5 KiB   gdm-binary [updated]
476.0 KiB +  97.5 KiB = 573.5 KiB   gvfsd [updated]
512.0 KiB +  89.0 KiB = 601.0 KiB   dconf-service [updated]
516.0 KiB + 140.5 KiB = 656.5 KiB   gvfs-afc-volume-monitor [updated]
568.0 KiB + 152.5 KiB = 720.5 KiB   gvfs-gphoto2-volume-monitor [updated]
532.0 KiB + 189.0 KiB = 721.0 KiB   gconf-helper [updated]
516.0 KiB + 240.0 KiB = 756.0 KiB   avahi-daemon [updated] (2)
828.0 KiB +  61.5 KiB = 889.5 KiB   bluetoothd
816.0 KiB + 173.0 KiB = 989.0 KiB   accounts-daemon [updated]
880.0 KiB + 229.5 KiB =   1.1 MiB   imsettings-daemon [updated]
928.0 KiB + 201.5 KiB =   1.1 MiB   deja-dup-monitor [updated]
972.0 KiB + 210.5 KiB =   1.2 MiB   upowerd [updated]
  1.1 MiB + 119.5 KiB =   1.2 MiB   modem-manager [updated]
940.0 KiB + 275.0 KiB =   1.2 MiB   wpa_supplicant [updated]
916.0 KiB + 302.5 KiB =   1.2 MiB   gdm-session-worker.#prelink#.39HoGs 
[deleted]
972.0 KiB + 290.0 KiB =   1.2 MiB   gsd-printer [updated]
  1.0 MiB + 230.5 KiB =   1.3 MiB   gdm-simple-slave [updated]
  1.1 MiB + 250.5 KiB =   1.3 MiB   gvfs-gdu-volume-monitor [updated]
  1.4 MiB +  37.0 KiB =   1.4 MiB   crond [updated]
  1.4 MiB +  73.5 KiB =   1.5 MiB   gconfd-2 [updated]
  1.1 MiB + 418.5 KiB =   1.5 MiB   udisks-daemon [updated] (2)
  1.3 MiB + 325.5 KiB =   1.6 MiB   sshd
  1.3 MiB + 377.0 KiB =   1.7 Mi

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17

[Pádraig Brady]

On 01/02/2012 06:03 PM, Jim Meyering wrote:
> Nils Philippsen wrote:
> ...
>> I've attached a list of packages and (co)maintainers, to easily find if
>> one of your packages is affected or not.
> ...
>> iwhd: meyering - clalance,zaitcev
> 
> Thank you for the list.
> 
> I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
> (built manually: 4.7.0 20111202), and it worked fine, so I'm not quite
> sure why iwhd is on the list.  Maybe the gcc-4.7.x that Jakub used
> lacks something that's in my Dec 2 snapshot, or maybe it's simply a
> problem in a dependent that has been fixed in the interim.
> 
> Oh!!! I see it.
> The tested version (the one in rawhide) is iwhd-1.1,
> while the latest is 1.2 (which is in F16).  Shame on me
> for not putting the latest also in rawhide.
> 
> Is there some sort of reminder service that could be configured
> to nag the maintainers of a package in a situation like this?
> Personally, I would appreciate it, and I think Fedora would
> benefit if we could do something to minimize reverse-version
> skew between Fedora-latest and rawhide.
> 
> Even if it's just a weekly posting of offenders to fedora-devel,
> so people know it's an issue...

I recently tried to add an F16 update without having the build in rawhide,
and the update was rejected, saying the last built version in rawhide
was older.  I used the web interface to generate the update, but surely
that logic is not just in the web interface?

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F17 heads up: gnome-shell for everyone!

[Pádraig Brady]

On 11/08/2011 12:45 AM, Adam Williamson wrote:
> On Tue, 2011-11-08 at 09:31 +1100, Bojan Smojver wrote:
> 
>> I think what will most likely happen is that someone out there will come
>> up with an extension to nuke the Activities button and replace it with
>> Applications button. And that will be the end of that discussion.
> 
> There's been one for months, and yet 'the end of that discussion' does
> not appear to have come, and not all Shell users use it.
> 
> http://intgat.tigress.co.uk/rmy/extensions/index.html

I also found the recent Linux Mint approach sensible.
http://blog.linuxmint.com/?p=1851
They're getting lots of unity defectors.
To me it seems like low hanging fruit to install some
of these extensions + gnome-tweak-tool on Fedora
and integrate these options into the settings panel
(even as an "extra-settings" item that starts gnome-tweak-tool).

I realize that options are often a sign of incomplete software,
but with direct user interaction, options can be a necessary evil
to deal with people's tastes and expectations.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)

[Pádraig Brady]

This feature is going to cause a lot of churn.
Aside from the huge changes within fedora I
think a bigger issue will be downstream of fedora
where third party packages and configs will
require large changes.  I would worry we might
alienate our users a bit with this?

Now I'm all for clean up, but sometimes it
may have to be done piecemeal for pragmatic reasons.

Could someone please enlighten me on the functional
benefits of moving everything to /usr?
I can see the clean up benefits of splitting things by
mutability/persistence, with the proposed scheme being:

 /etc - non-shareable, can be read-only, host-only configuration
 /usr - shareable, can be read-only, package managed, binaries
 /var - non-shareable, writable, host-only state/data
 /run - temporary state

However the existing hierarchy can be quite easily adjusted.
For example I previously worked with a Fedora 14 system
on installations of up to 1000 systems that were organized like:

 /tmp - temporary state (rw) (ram)
 /var - host state (rw) (nfs)
 /etc/dev - device state³ (rw) (local disk/flash etc.)
 /... - the rest¹ (ro²) (nfs)

¹ The rest was a single file system. I've never mounted
/usr as a separate file system anyway.

² Note there were a few places in the rest of the hierarchy
that needed to be bind mounted to the (rw) locations,
but they were minimal and encapsulated in /etc/statetab.d/blah
Also it seemed quite elegant in the case of /etc for example
to have all the config together, with only a couple of places
auto bind mounted to (rw).

³ Stuff like touchscreen calibration settings.

Also about snapshots. This is possible (better?) when
done from the source location. I.E. in my example above,
the (ro) nfs directory was easily copied or directed
to a new release directory.  For local systems the
equivalent would be doing a snapshot of the (ro) file system
at the file system level (like BTRFS supports), rather than
going down through the file hierarchy which seems inefficient
and racy.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Pádraig Brady]

On 23/06/11 16:21, Pádraig Brady wrote:
> On 23/06/11 15:53, Karel Zak wrote:
>>  https://bugzilla.redhat.com/show_bug.cgi?id=709351
>>
>> The tools (not only df(1)) have to be fixed to de-duplicate the list
>> of fileststems. It's standard behavior that the same filesystem could
>> be mounted on more places. 
>>
>> The 'bind' flag is another way how to achieve that the filesystem is
>> mounted on another place. Nothing other.
>>
>># mount /dev/sdb1 /mnt/A
>># mount --bind /mnt/A /mnt/B
>>
>> is the same thing as:
>>
>># mount /dev/sdb1 /mnt/A
>># mount /dev/sdb1 /mnt/B 
>>
>> there is nothing like 'bind' state of the filesystem. The 'bind' info in
>> mtab was always broken by design.
>>
>> http://karelzak.blogspot.com/2011/04/bind-mounts-mtab-and-read-only.html
> 
> Thanks for that info.
> 
> I did a find_bind_mount() function as part of:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ddf6fb86

That's no longer valid.
Looks like I'll need to separately parse /proc/self/mountinfo
if we need that functionality :(
I'm sure there was a very good reason for changing that?

> I also adjusted df to handle bind mounts better with:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=0380e4c9
> I'll have to revisit these to see if they're still valid.

That one seems less necessary now.

> I'll have a look at fixing up df (I guess I'll reverse the mount list
> and have some internal hash to detect dupes?).

I had a 5 min look and I don't think it will be this easy.

> I need to see why F15 has started doing this too.
> For example on my system there are 2 _identical_ entries
> for /home in /proc/mounts.

I've not got sandbox installed BTW.
Still need to look at this.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [INFO] New benchmark on SELINUX and Fedora 15 from Phoronix

[Pádraig Brady]

On 23/06/11 14:45, Daniel J Walsh wrote:
> On 06/23/2011 08:58 AM, Pádraig Brady wrote:
>> On 23/06/11 12:28, Lennart Poettering wrote:
>>> On Thu, 23.06.11 12:58, yersinia (yersinia.spi...@gmail.com) wrote:
>>>
>>>> Greetings
>>>>
>>>> Perhaps it is of interest to this list that Phonorix has produced a new
>>>> benchmark about the performance impact of SELinux on
>>>> Fedora 15. Look very good
>>>> http://www.phoronix.com/scan.php?page=article&item=fedora_15_selinux&num=2.
>>>
>>> The biggest impact it has on boot time really. Might be worth measuring 
>>> that.
> 
>> A work colleague here did that a couple of days ago.
>> To boot to a usable desktop with stock F15 with gdm auto login:
> 
>>   with selinux:43s
>>   without selinux: 24s
> 
>> Hardware is pinetrail netbook (1.6GHz Atom N455).
>> 2GB RAM and SSD limited by SATA I interface.

Repeating the above on my F15 sandy bridge i3 laptop
shows a much closer result:

  with selinux:18s
  without selinux: 14s

> We have found one problem in libselinux that could account for some of
> the slowdown, but not much, this increases the spead of matchpathcon.
> We have fixed this in F16.
> 
> Tests conducted in Rawhide.
> 
> systemd reads in policy file and loads it in the kernel.
> 
> # du -m /etc/selinux/targeted/policy/policy.26
> 7 /etc/selinux/targeted/policy/policy.26
> 
> The load_policy command on my T61 does pretty much the equivalent.
> 
> # time load_policy
> 
> real  0m7.483s
> user  0m0.000s
> sys   0m2.255s
> 
> systemd and udev both load the file_context files and create regexs
> based on these files.  matchpathcon does the equivalent.
> 
> time matchpathcon /dev
> /dev  system_u:object_r:device_t:s0
> 
> real  0m0.069s
> user  0m0.012s
> sys   0m0.021s
> 
> Obviously this is a more powerful machine then the Atom, but I would
> figure loading of the policy is the culprit.

snb# time matchpathcon /dev
/devsystem_u:object_r:device_t:s0

real0m0.101s
user0m0.096s
sys 0m0.004s

snb# time load_policy

real0m1.553s
user0m0.000s
sys 0m0.483s

atom# time matchpathcon /dev
/devsystem_u:object_r:device_t:s0

real0m1.036s
user0m1.012s
sys 0m0.019s

atom# time load_policy

about 4s

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Pádraig Brady]

On 23/06/11 15:53, Karel Zak wrote:
>  https://bugzilla.redhat.com/show_bug.cgi?id=709351
> 
> The tools (not only df(1)) have to be fixed to de-duplicate the list
> of fileststems. It's standard behavior that the same filesystem could
> be mounted on more places. 
> 
> The 'bind' flag is another way how to achieve that the filesystem is
> mounted on another place. Nothing other.
> 
># mount /dev/sdb1 /mnt/A
># mount --bind /mnt/A /mnt/B
> 
> is the same thing as:
> 
># mount /dev/sdb1 /mnt/A
># mount /dev/sdb1 /mnt/B 
> 
> there is nothing like 'bind' state of the filesystem. The 'bind' info in
> mtab was always broken by design.
> 
> http://karelzak.blogspot.com/2011/04/bind-mounts-mtab-and-read-only.html

Thanks for that info.

I did a find_bind_mount() function as part of:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ddf6fb86
I also adjusted df to handle bind mounts better with:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=0380e4c9
I'll have to revisit these to see if they're still valid.

I'll have a look at fixing up df (I guess I'll reverse the mount list
and have some internal hash to detect dupes?).

I need to see why F15 has started doing this too.
For example on my system there are 2 _identical_ entries
for /home in /proc/mounts.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [INFO] New benchmark on SELINUX and Fedora 15 from Phoronix

[Pádraig Brady]

On 23/06/11 12:28, Lennart Poettering wrote:
> On Thu, 23.06.11 12:58, yersinia (yersinia.spi...@gmail.com) wrote:
> 
>> Greetings
>>
>> Perhaps it is of interest to this list that Phonorix has produced a new
>> benchmark about the performance impact of SELinux on
>> Fedora 15. Look very good
>> http://www.phoronix.com/scan.php?page=article&item=fedora_15_selinux&num=2.
> 
> The biggest impact it has on boot time really. Might be worth measuring that.

A work colleague here did that a couple of days ago.
To boot to a usable desktop with stock F15 with gdm auto login:

  with selinux:43s
  without selinux: 24s

Hardware is pinetrail netbook (1.6GHz Atom N455).
2GB RAM and SSD limited by SATA I interface.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)

[Pádraig Brady]

On 17/06/11 12:17, Dennis Jacobfeuerborn wrote:
> On 06/17/2011 01:02 PM, Richard W.M. Jones wrote:
>> I can't believe real usability testing was done on the final version
>> of GNOME 3.  I keep hearing about all these completely undiscoverable
>> keyboard shortcuts that appear to be necessary to use GNOME 3 with any
>> sort of effectiveness.  When I struggled with GNOME 3 for about a week
>> I didn't discover or use any keyboard shortcuts.
> 
> I think what is required is an application that starts when the desktop is 
> launched for the first time and that offers the user a short introduction 
> to the basic principles of the desktop.
> Easy discoverability and good usability may sometimes go hand in hand but 
> also at times are mutual exclusive. Having a short introductory "pamphlet" 
> would help the user understand the basics without resorting to awkward 
> tool-tips or pop-ups to nudge the user in the right direction.

KISS. F1 should launch the "help app" by default.
It's configured to do so, but doesn't. I presume there's a bug for that.
After a couple of days I typed "help" in the search box and was enlightened.
This help does have an intro section, but it's long winded.
There should be a TL;DR section presented first with basic navigation and 
shortcuts.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide

[Pádraig Brady]

On 24/11/10 01:41, Matthew Miller wrote:
> On Tue, Nov 23, 2010 at 11:54:47PM +0100, Lennart Poettering wrote:
>> I think the fact that we get less disks accesses (just think noatime and
>> stuff for the files dropped there) is more interesting than using the
>> absolute minimal amount of memory.
> 
> Less disk access at startup, or in general somehow? Optimizing for startup
> performance over general performance does not seem so good. But this is
> really about elegance rather than resource usage, right?
> 
> Currently, /var/run and /var/lock on my rawhide desktop system take up 364K.
> 385K on another rawhide system. (Blocksize of 4k.) I think we can spare that
> in this day and age if we get a reasonable benefit in return.
> 
> Meanwhile, NetworkManager is doing absolutely nothing for me, and is taking
> up a USS of 65.3M. If we're gonna tilt at memory consumption windmills, how
> about we take a look at that one?
> 
> (NetworkManager is awesome on my _laptop_, by the way. Wouldn't dream of
> living without it.)

Here is the RAM usage on my 11 day uptime F14 laptop

$ sudo ps_mem.py¹

 Private  +   Shared  =  RAM used   Program

  1.9 MiB + 252.5 KiB =   2.1 MiB   NetworkManager [updated]
  7.0 MiB +   1.6 MiB =   8.6 MiB   nm-applet [updated]

I notice both were updated so restarting gives:

$ sudo ps_mem.py

  1.4 MiB + 290.0 KiB =   1.7 MiB   NetworkManager
  2.6 MiB +   1.3 MiB =   3.9 MiB   nm-applet

[1] http://www.pixelbeat.org/scripts/ps_mem.py
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide

[Pádraig Brady]

On 23/11/10 20:48, Lennart Poettering wrote:
> Heya!
> 
> I hereby want to let everybody know that in the next days I will turn on
> /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
> with the following accepted F15 feature:

We run stateless systems here and both of the above
directories are listed in the default /etc/rwtab.
We've not noticed any issues with that
(note we disable selinux).

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Developers of packages please pay attention to selinux labeling.

[Pádraig Brady]

On 13/07/10 16:57, Matěj Cepl wrote:
> Dne 13.7.2010 17:33, Pádraig Brady napsal(a):
>> Personally I do momentarily enable to test but always disable
>> because of _hundreds_ of errors in the applet thingy.
> 
> Hundreds? I have been running RHEL-6 from mid-Januray (that means 
> Rawhide was quite stable comparing to it) with SELinux in the Enforcing 
> mode with even special SELinux user staff_u and I just don't see 
> *hundreds* bugs on day-to-day basis. I was very faithful in filing ALL 
> SELinux issues to bugzilla and I am quite sure it wasn't hundred so far.

To be clear, the "hundreds" contained many duplicates.
I'm not complaining since I haven't looked into any
of these issues, I'm just trying to provide insight
into why SELinux might not be as tested as one would like.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Developers of packages please pay attention to selinux labeling.

[Pádraig Brady]

On 13/07/10 15:47, Tomasz Torcz wrote:
> On Tue, Jul 13, 2010 at 03:11:44PM +0100, Christopher Brown wrote:
>>>
>>> As long as you give us a heads up we can prevent these types of blowups.
>>> Since this policy is shared between yum, packagekit
>>
>> Whilst I appreciate your huge efforts to provide users with a more
>> secure system, you need to realise that SELinux as it stands at the
>> moment is utterly broken. As you clearly don't think this is the case,
>> please spend some time in userland before beating on developers for
>> not caring about this.
> 
> 
>   On the other hand, I cannot understand why packagers submit packages that
> have no chance to work in default Fedora settings, with SELinux in Enforcing 
> mode.

Nobody I know enables SELinux.
smolt says about half leave it enabled:
http://smolts.org/static/stats/stats.html
But I'm guessing a lot of experienced users/devs
disable it given previous experiences...
It's a bit of a catch 22 really.

Personally I do momentarily enable to test but always disable
because of _hundreds_ of errors in the applet thingy.
Enabling in non enforcing mode causes a huge performance hit,
causing for example the "do you want to kill" dialog to pop up
when I try to quit firefox.

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gethostbyname() and resolv.conf updates

[Pádraig Brady]

On 21/06/10 15:40, Colin Walters wrote:
> On Sat, Jun 19, 2010 at 10:54 PM, Dan Williams  wrote:
>>
>> I'm just gonna make NM use a local caching nameserver (which means
>> dnsmasq) by default at some point soon.  People that don't want it can
>> turn it off.
> 
> When thinking about this, there's a rather obvious patch here that
> really should have been made 5+ years ago...make it an option!  And
> this actually makes some sense, e.g. if NetworkManager writes out a
> static configuration, then there's no need to stat() on it since we
> can assume it won't change.  (This does still screw over server admins
> who hand-edit it, but...)
> 
> glibc and NetworkManager patches attached.
> 
> (I'm totally in favor of the dnsmasq approach too since the OS
> desperately needs DNS caching too, but this is a simple patch that
> doesn't conceptually conflict).

Sorry I haven't been following this really, but I loath
config options that aren't absolutely required, and this
seems like a place where we could just stat() (cache) always.
What's the problem with doing that?

Are we worried about the performance of doing time()
for every request? I would never expect anything
resembling efficiency from DHCP, never mind the
overhead of a time() call.
Has debian ever had complaints given that they
patch glibc by default?

cheers,
Pádraig.

p.s. not having looked at the code,
the atomic ops seems unusual in the
presence of the static last_... variables.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel