Re: logrotate(8) and copytruncate as default
On Thu, 2013-06-27 at 18:41 -0400, Colin Walters wrote: On Thu, 2013-06-27 at 23:38 +0200, Lennart Poettering wrote: Why would you want this? I mean, we rate-limit per-service anyway, so the issue of one app flooding evreything else should be mostly non-existant. And hence, what you are asking for is some policy control about what to delete first, which only really matters if your disk space is very very limited? Would you consider it sane to log say Apache traffic to the journal? If not, then there's still logrotate in the picture, and daemons need to do the whole SIGHUP dance. You can ignore the rest of this message in that case. But if you do, then it would seem fairly sane to me on a medium traffic site to want the ability to have different retention policies for the webserver logs versus other system events like sudo activations or a change of the root password. I'm not entirely sure how this works, but in some sense, journal separates logs *by uid* - if you look in /var/log/journal , there are files for root and files for your uid. If you were logging httpd via the journal, it may be that it'd wind up in a different journal file for the uid httpd was being run as. I haven't checked if you can set rotation policies on a per-uid level. (I'm sure Lennart can explain this more, er, correctly.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libgd breakage
On 27/06/13 17:31, Orion Poplawski wrote: On 06/26/2013 08:01 AM, Volker Fröhlich wrote: GDAL is currently broken because it needs a rebuild for Poppler, but the Texlive build is broken, as far as I can see. texlive has now been rebuilt. We've got a working GDAL build again. Volker -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Media Sizes SRPMS DVD
On Thu, 27 Jun 2013 20:52:25 -0500 Dennis Gilmore den...@ausil.us wrote: The tooling can not make split media. its not possible. I meant us in Freemedia? on our own pcs -- Regards, Frank When in doubt PANIC! I check for new mail app. 20min www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Tinyproxy - provenpackager intervention needed (760474)
Hi, Tinyproxy package has a problem since F16 - because of missing tmpfilesd snippet, the program won't start without intervention of admin. Tinyproxy wnats to store pidfile in /run/tinyproxy. This directory does not exist after fresh boot. There's a bug open: https://bugzilla.redhat.com/show_bug.cgi?id=760474 Yesterday I attached a .spec patch to the bug. Patch provides tmpfilesd file and systemd unit file as a bonus. Can someone commitbuild, so at least we have working tinyproxy package for F19? Thanks, -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) pgpSQYlmQ958k.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hello Jan,
- Original Message -
From: Jan Kaluza jkal...@redhat.com
Subject: Re: logrotate(8) and copytruncate as default
Right now, without locking, logrotate would loss more messages if the
logs are big, because copying takes more time. It would be interesting
to mention the file size in your tests too.
===
#!/bin/sh
#
# flockexp.sh: is a simple experiment to create a large log file and
# copy-truncate it when its size reaches a predefined limit.
#
if [ $# -lt 2 ]; then
echo Usage: $0 output-file maxsize;
exit 0;
fi
# main
{
$1;
logsize=$2;
watch if [ \`stat -c '%s' $1\` -gt $logsize ]; \
then flock -x $1 -c 'cp $1 $1.1; $1'; fi /dev/null
count=0;
while (true);
do
count=`expr $count + 1`;
echo `date +%d %a %Y %T` $count `grep 'MemFree' /proc/meminfo`;
done $1;
}
===
I tried it with different file sizes. It starts showing data loss as size
grows 2MB.
===
$ stat -c '%s' test.log test.log.1
418065
2007074
$
$ tail -n 4 test.log.1
28 Fri 2013 17:20:28 42937 MemFree: 3655640 kB
28 Fri 2013 17:20:28 42938 MemFree: 3655580 kB
28 Fri 2013 17:20:28 42939 MemFree: 3655068 kB
28 Fri 2013 17:20:28 42940 MemFree: 3655436 kB
$
$ head -n 4 test.log
28 Fri 2013 17:20:28 42942 MemFree: 3655428 kB
28 Fri 2013 17:20:28 42943 MemFree: 3655448 kB
28 Fri 2013 17:20:28 42944 MemFree: 3655812 kB
28 Fri 2013 17:20:28 42945 MemFree: 3655824 kB
===
I guess kernel buffers start dropping writes after very short limit.
---
Regards
-Prasad
http://feedmug.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remove package and all dependent packages from EL branch?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2013 01:50 AM, Peter Lemenkov wrote: Hello. I've got bugreport that Erlang doesn't work on EL6 PPC64 achitecture. https://bugzilla.redhat.com/show_bug.cgi?id=958953 I don't have resources to fix this issue, and nobody volunteered to fix it so far, so I'd like to limit Erlang, and Erlang applications and libraries on EL6 to x86/x86_64, where they works for sure. It's not the only issue with Erlang and PPC64 - it also has limited support for Java which prevented Erlang-Java bridge from being built successfully. Reducing Erlang on EL6 to architectures where it works even allows me to drop one patch and remove a couple of ifdefs from spec so this will simplify things a bit. Is there any documentation which describes the process of package removal from a particular EL hardware branch? -- With best regards, Peter Lemenkov. Your best bet would be to add ppc64 to the ExclusiveArch on erlang, rebuild it, get it pushed to stable, then the broken deps would make it clear what packages were descended from it (and can also be patched then to exclude ppc64). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHNhUgACgkQeiVVYja6o6M2GQCgrQ3UBtHTt28yLeatp6XS6h8C ll4An2GF7/4XYU8yXoJBWV2JoSyv9tEP =Zb6b -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130628 changes
Compose started at Fri Jun 28 09:15:03 UTC 2013 Broken deps for x86_64 -- [avgtime] avgtime-0-0.5.git20120724.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [dsqlite] dsqlite-1.0-4.fc19.i686 requires libphobos-ldc.so.60 dsqlite-1.0-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [dustmite] dustmite-1-8.20121031git1fb3ac4.fc18.x86_64 requires libphobos-ldc.so.60()(64bit) [freeipa] freeipa-server-strict-3.2.1-1.fc19.x86_64 requires pki-ca = 0:10.0.2 freeipa-server-strict-3.2.1-1.fc19.x86_64 requires 389-ds-base = 0:1.3.1.0 [gl3n] gl3n-0.20120813-4.fc19.i686 requires libphobos-ldc.so.60 gl3n-0.20120813-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [nodejs-tilelive] nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) 0:0.4 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [tango] tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60 tango-2-12.20120821git7b92443.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [avgtime] avgtime-0-0.5.git20120724.fc19.i686 requires libphobos-ldc.so.60 [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ
Re: Tinyproxy - provenpackager intervention needed (760474)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2013 05:43 AM, Tomasz Torcz wrote: Hi, Tinyproxy package has a problem since F16 - because of missing tmpfilesd snippet, the program won't start without intervention of admin. Tinyproxy wnats to store pidfile in /run/tinyproxy. This directory does not exist after fresh boot. There's a bug open: https://bugzilla.redhat.com/show_bug.cgi?id=760474 Yesterday I attached a .spec patch to the bug. Patch provides tmpfilesd file and systemd unit file as a bonus. Can someone commitbuild, so at least we have working tinyproxy package for F19? If you can get someone else to review and ack the proposed patch, I'll apply it to the package and get it rebuilt. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEUEARECAAYFAlHNhd4ACgkQeiVVYja6o6MLbwCXXOkCQkA8uJreClyJEwLSmXbq mwCfcY/tkCnu7VGQcjXrtjmD+N0Q1R8= =M3HQ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tinyproxy - provenpackager intervention needed (760474)
On 06/28/2013 12:47 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2013 05:43 AM, Tomasz Torcz wrote: Hi, Tinyproxy package has a problem since F16 - because of missing tmpfilesd snippet, the program won't start without intervention of admin. Tinyproxy wnats to store pidfile in /run/tinyproxy. This directory does not exist after fresh boot. There's a bug open: https://bugzilla.redhat.com/show_bug.cgi?id=760474 Yesterday I attached a .spec patch to the bug. Patch provides tmpfilesd file and systemd unit file as a bonus. Can someone commitbuild, so at least we have working tinyproxy package for F19? If you can get someone else to review and ack the proposed patch, I'll apply it to the package and get it rebuilt. Who's maintaining this package and where is that maintainer? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tinyproxy - provenpackager intervention needed (760474)
On Fri, Jun 28, 2013 at 12:46:52PM +, Jóhann B. Guðmundsson wrote: On 06/28/2013 12:47 PM, Stephen Gallagher wrote: Tinyproxy package has a problem since F16 - because of missing tmpfilesd snippet, the program won't start without intervention of admin. Tinyproxy wnats to store pidfile in /run/tinyproxy. This directory does not exist after fresh boot. There's a bug open: https://bugzilla.redhat.com/show_bug.cgi?id=760474 Yesterday I attached a .spec patch to the bug. Patch provides tmpfilesd file and systemd unit file as a bonus. Can someone commitbuild, so at least we have working tinyproxy package for F19? If you can get someone else to review and ack the proposed patch, I'll apply it to the package and get it rebuilt. Who's maintaining this package and where is that maintainer? Jeremy Hinegardner - jjh in Fedora. And where he is.. that's a good question. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Architecture specific header files
Dne 25.6.2013 15:41, Vít Ondruch napsal(a):
Hi,
Is there some common practice, where to place architecture specific
header files? From output of the following command, I can't see any
such place.
$ `gcc -print-prog-name=cc1` -v
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/include-fixed
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/include
/usr/local/include
/usr/include
End of search list.
Actually, the ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.8.1/../../../../x86_64-redhat-linux/include
might be usable, but is it allowed to use it? Does it conform to FHS
(don't think so). Shouldn't it be configured differently?
The point is, that compilation of this simple program:
$ cat rt.c
#include ruby.h
int main(int argc, char **argv)
{
return 0;
}
^D
fails:
$ gcc rt.c
In file included from /usr/include/ruby.h:33:0,
from rt.c:1:
/usr/include/ruby/ruby.h:24:25: fatal error: ruby/config.h: No such
file or directory
#include ruby/config.h
^
compilation terminated.
This should work out of the box IMO, without any configuration or
specification of additional paths etc. The problem is, that Ruby ships
architecture specific config.h header which is not available in GCC's
default search path and I am wondering how to make this work.
Thanks
Vít
Since it seems that this is quite common issue and there are more
packages needing to workaround this issue (Python is not mentioned in
this thread yet), I took the liberty to open RFE at GCC:
https://bugzilla.redhat.com/show_bug.cgi?id=979403
Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tinyproxy - provenpackager intervention needed (760474)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2013 08:53 AM, Tomasz Torcz wrote: On Fri, Jun 28, 2013 at 12:46:52PM +, Jóhann B. Guðmundsson wrote: On 06/28/2013 12:47 PM, Stephen Gallagher wrote: Tinyproxy package has a problem since F16 - because of missing tmpfilesd snippet, the program won't start without intervention of admin. Tinyproxy wnats to store pidfile in /run/tinyproxy. This directory does not exist after fresh boot. There's a bug open: https://bugzilla.redhat.com/show_bug.cgi?id=760474 Yesterday I attached a .spec patch to the bug. Patch provides tmpfilesd file and systemd unit file as a bonus. Can someone commitbuild, so at least we have working tinyproxy package for F19? If you can get someone else to review and ack the proposed patch, I'll apply it to the package and get it rebuilt. Who's maintaining this package and where is that maintainer? Jeremy Hinegardner - jjh in Fedora. And where he is.. that's a good question. Looks to me like this package has been just carried along with only mass-rebuilds since 2010... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHNiGQACgkQeiVVYja6o6MLXQCeMiERnOQl+b0Th7yTpmftJHUv xlIAn1Ng9iiG0HVFJOLA0EsQA7e4ku7F =+Hz4 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remove package and all dependent packages from EL branch?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/28/2013 08:44 AM, Stephen Gallagher wrote:
On 06/28/2013 01:50 AM, Peter Lemenkov wrote:
Hello. I've got bugreport that Erlang doesn't work on EL6 PPC64
achitecture.
https://bugzilla.redhat.com/show_bug.cgi?id=958953
I don't have resources to fix this issue, and nobody volunteered
to fix it so far, so I'd like to limit Erlang, and Erlang
applications and libraries on EL6 to x86/x86_64, where they
works for sure. It's not the only issue with Erlang and PPC64 -
it also has limited support for Java which prevented Erlang-Java
bridge from being built successfully. Reducing Erlang on EL6 to
architectures where it works even allows me to drop one patch
and remove a couple of ifdefs from spec so this will simplify
things a bit.
Is there any documentation which describes the process of package
removal from a particular EL hardware branch? -- With best
regards, Peter Lemenkov.
Your best bet would be to add ppc64 to the ExclusiveArch on
erlang, rebuild it, get it pushed to stable, then the broken deps
would make it clear what packages were descended from it (and can
also be patched then to exclude ppc64).
Of course, I meant that you should be using
ExclusiveArch: %{ix86} x86_64
Adding ppc64 to that list would be the opposite of what you want...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHNiSMACgkQeiVVYja6o6MCzACfUCq6Jt7NSVPJsVS+VBcp1LtL
QVEAnRLRd44q5dOC5Sj2hpfAr7TxzncU
=vbHa
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Architecture specific header files
On Fri, Jun 28, 2013 at 02:58:12PM +0200, Vít Ondruch wrote: Dne 25.6.2013 15:41, Vít Ondruch napsal(a): Is there some common practice, where to place architecture specific header files? From output of the following command, I can't see any such place. gcc doesn't have such location, you'd want a different path for gcc -m64, different for gcc -m32, different for gcc -mx32, The standard way is to add a wrapper header and include your arch specific header based on compiler predefined macros. Say something like: # ifdef __i386__ # include asm/posix_types_32.h # elif defined(__ILP32__) # include asm/posix_types_x32.h # else # include asm/posix_types_64.h # endif or, if possible, avoid arch specific headers altogether. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Fri, 28.06.13 13:23, P J P (pj.pan...@yahoo.co.in) wrote: The systemd-journald takes care of all of: receiving messages, writing them to storage, and rotating the storage. We do synchronous rotation before each write. i.e. the moment we append to a file we check if the write would cause the disk usage to be out of limits, and then do the rotation right away. I see. While doing this rotation, I guess systemd uses flock(2) or similar mechanism to pause writing to a log file, move/rename or copy-truncate that file and continue writes again? journald is the only writer, it doesn't need locking. The changes it does are done in a way so that concurrent readers will either see the changes or not, but never half-written changes. Also note that locking on Linux is seriously broken. You can get a lock on any file you can read, thus you can freeze everybody else who might want a lock. Or in other words: if a logging daemon takes a lock on its lock files, then you can use this to make that service freeze forever. File system locking on Unix cannot really work. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
yum groupinstall development-tools FAILS
People, This command: yum groupinstall development-tools fails with these errors: Transaction Check Error: file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 Are there workarounds or fixes? Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: p...@pricom.com.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum groupinstall development-tools FAILS
On Fri, Jun 28, 2013 at 10:32 AM, Philip Rhoades p...@pricom.com.au wrote: People, This command: yum groupinstall development-tools fails with these errors: Transaction Check Error: file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package try yum -y install @development-tools --enablerepo=updates-testing Itamar Reis Peixoto -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tinyproxy - provenpackager intervention needed (760474)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Jun 28, 2013 at 11:43:44AM +0200, Tomasz Torcz wrote: Tinyproxy package has a problem since F16 - because of missing tmpfilesd snippet, the program won't start without intervention of admin. Tinyproxy wnats to store pidfile in /run/tinyproxy. This directory does not exist after fresh boot. There's a bug open: https://bugzilla.redhat.com/show_bug.cgi?id=760474 There is also a couple open CVEs that have been patched upstream. I sent the maintainer and email earlier this week and was waiting to hear back from him before bringing it to the devel list. It would be great if someone could push the latest version into Fedora. - -- Eric - -- Eric Sparks Christensen Fedora Project - Red Hat spa...@redhat.com - spa...@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) iQGcBAEBCgAGBQJRzZSsAAoJEB/kgVGp2CYvJfsL/igDdi/OBrpiAu1y9liFvMIi MkPEZNB2N6M+X6LoQmP+liRs/Vg8k7cHkBVxYFoD2Np36wAkOdaYivSrHbRKaccH JRB/TnnPHaTxCGgo6Bo/7rwEQ489vXpytxGzKWUAdzE/JbXZew8qMy9gJWPlexXN oFZxicQ5a0i8DE93HMOPs+gCG5oeXSc5vB3LE/+2AXnSU0jjRo3CSDoE1AcS6FSz Pvz8D4jgmWQKevkYGLy5XyEQOMgJ0hw9McMVbY4XvGxzsDVRtMr8YT1nx2b5ZuCw X+vKOaHQZSQx0qhyZ3PfPzKPbI9NEEt+vn1t0NTbcPioIGh3R8fCMqTbKLaGN3fI MlUJv8yBjB2saqdua0RXfcQNBVOQamEMW0CU47gmwGMoRgIGHH82Ub2WQr43Zu34 DGcoOxAtSclCJC3nmb8YYq07szCHbF0y96V6V1PxXQ/Wm+DyqLkd9V/wpLn6tFWp ddhNNpwfSiXmNGnwSoTBGbqtI79FC0TvMiBVEqmlgA== =lwHz -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum groupinstall development-tools FAILS
On 06/28/2013 03:32 PM, Philip Rhoades wrote: People, This command: yum groupinstall development-tools fails with these errors: Transaction Check Error: file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 Are there workarounds or fixes? Thanks, Phil. There's this bug https://bugzilla.redhat.com/show_bug.cgi?id=915247 You could --exclude=systemtap-sdt-devel* to get past it if you don't need this package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum groupinstall development-tools FAILS
Brendan, On 2013-06-28 23:47, Brendan Jones wrote: On 06/28/2013 03:32 PM, Philip Rhoades wrote: People, This command: yum groupinstall development-tools fails with these errors: Transaction Check Error: file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-devel-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-runtime-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-client-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/en/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/fr/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 file /usr/share/locale/pl/LC_MESSAGES/systemtap.mo from install of systemtap-2.2.1-1.fc18.x86_64 conflicts with file from package systemtap-sdt-devel-2.1-2.fc18.x86_64 Are there workarounds or fixes? Thanks, Phil. There's this bug https://bugzilla.redhat.com/show_bug.cgi?id=915247 You could --exclude=systemtap-sdt-devel* to get past it if you don't need this package. yum --exclude=systemtap-sdt-devel* groupinstall development-tools still gives the same errors . . Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: p...@pricom.com.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
delays between kernel builds and updates-testing
why does yum --enablerepo=updates-testing -q check-update --security today the first time show a kernel built a week ago? this is *way* too long to get it in *updates-testing* and after that wait forever to go to stable while 3.9.8 is still built, and new builts especially security relevant ones must not lay around on koji for days and weeks without hit users with enabled updates-testing __ http://koji.fedoraproject.org/koji/buildinfo?buildID=428473 Completed: Fri, 21 Jun 2013 18:58:40 UTC kernel.x86_64 3.9.7-100.fc17-testing kernel-headers.x86_64 3.9.7-100.fc17-testing first time seen froma daily-cronjob today __ signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Architecture specific header files
Dne 28.6.2013 15:04, Jakub Jelinek napsal(a): On Fri, Jun 28, 2013 at 02:58:12PM +0200, Vít Ondruch wrote: Dne 25.6.2013 15:41, Vít Ondruch napsal(a): Is there some common practice, where to place architecture specific header files? From output of the following command, I can't see any such place. gcc doesn't have such location Could you please consider to add such location? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: delays between kernel builds and updates-testing
On Fri, Jun 28, 2013 at 12:36:24 +0200, Reindl Harald h.rei...@thelounge.net wrote: why does yum --enablerepo=updates-testing -q check-update --security today the first time show a kernel built a week ago? this is *way* too long to get it in *updates-testing* and after that wait forever to go to stable while 3.9.8 is still built, and new builts especially security relevant ones must not lay around on koji for days and weeks without hit users with enabled updates-testing Because only one kernel can be queued up in testing and kernels get updated faster than they get karma to get into stable. So if testing kernels got replaced as soon as there were new updates available, they may never get to stable. If you want to help with this test kernels on the older releases and give appropriate feedback in bohdi for them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum groupinstall development-tools FAILS
Philip Rhoades p...@pricom.com.au writes: [...] yum --exclude=systemtap-sdt-devel* groupinstall development-tools still gives the same errors . . How about a yum update systemtap\* first? - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: delays between kernel builds and updates-testing
Am 28.06.2013 16:49, schrieb Bruno Wolff III: On Fri, Jun 28, 2013 at 12:36:24 +0200, Reindl Harald h.rei...@thelounge.net wrote: why does yum --enablerepo=updates-testing -q check-update --security today the first time show a kernel built a week ago? this is *way* too long to get it in *updates-testing* and after that wait forever to go to stable while 3.9.8 is still built, and new builts especially security relevant ones must not lay around on koji for days and weeks without hit users with enabled updates-testing Because only one kernel can be queued up in testing and kernels get updated faster than they get karma to get into stable there was no 3.9.6 in updates-testing as 3.9.7 was built for a week So if testing kernels got replaced as soon as there were new updates available, they may never get to stable. which does not explain why 3.9.6 and 3.9.7 was not in updates-testing and 3.9.7 got there today, a week after it was built and after 3.9.8 was built on koji for F17 If you want to help with this test kernels on the older releases and give appropriate feedback in bohdi for them. this is a conceptional problem in the Fedora infrastructure http://koji.fedoraproject.org/koji/buildinfo?buildID=428473 Jun 23 22:41:36 Installed: kernel-3.9.7-100.fc17.x86_64 so if the would be a link from koji to give karma i would have done that last sunday as i installed it on my test-VM and as said having users testing kernels and many other packages often before the maintainer knows that the build has finished but make it hard for them to give karma is a conceptional problem hence i could give karma yet for 3.9.8-100.fc17.x86_64 #1 SMP Thu Jun 27 where? i have http://koji.fedoraproject.org/koji/buildinfo?buildID=429958 open in my browser, i deployed it to the backup-infrastructure which are 10 machines as well as on the production secondary nameserver and have to search around how to give karma - seriously? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: delays between kernel builds and updates-testing
On Fri, 28 Jun 2013 17:09:43 +0200 Reindl Harald h.rei...@thelounge.net wrote: ...snip... which does not explain why 3.9.6 and 3.9.7 was not in updates-testing and 3.9.7 got there today, a week after it was built and after 3.9.8 was built on koji for F17 Only the kernel maintainers can answer that. How about we wait and let them do that? If you want to help with this test kernels on the older releases and give appropriate feedback in bohdi for them. this is a conceptional problem in the Fedora infrastructure IMHO, no. Only those builds that maintainers desire to push out as updates are pushed out as updates. There's many reasons why someone would build something but not push it out (yet). Perhaps there was a very nasty bug and they wanted a reporter to confirm. Perhaps they did the build, but discovered some bug in their testing after the build completed. Anyhow, there's no point in repeating things here... lets wait for the kernel folks to let us know which case this was and move on with our lives. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: delays between kernel builds and updates-testing
On Fri, Jun 28, 2013 at 17:09:43 +0200, Reindl Harald h.rei...@thelounge.net wrote: so if the would be a link from koji to give karma i would have done that last sunday as i installed it on my test-VM and as said having users testing kernels and many other packages often before the maintainer knows that the build has finished but make it hard for them to give karma is a conceptional problem I agree that it would be nice to be able to give karma to packages once there are koji builds available. I don't think that would solve the problems with updates not getting karma in older releases, but it could help it a bit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remove package and all dependent packages from EL branch?
On Fri, Jun 28, 2013 at 2:44 PM, Stephen Gallagher sgall...@redhat.com wrote: Your best bet would be to add ppc64 to the ExclusiveArch on erlang, rebuild it, get it pushed to stable, then the broken deps would make it clear what packages were descended from it (and can also be patched then to exclude ppc64). Note also https://fedoraproject.org/wiki/Packaging:Guidelines?rd=PackagingGuidelines#Architecture_Build_Failures . Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Thu, Jun 27, 2013 at 07:34:06PM -0400, Jaroslav Reznik wrote: At the Fedora 19 Final Go/No-Go Meeting that just occurred, it was agreed to Go with the Fedora 19 by Fedora QA, development, release engineering and FPM. 979205 got filed yesterday, which makes it incredibly difficult to install F19 on Macs while keeping OS X. This is rather frustrating, since Fedora's the only distribution with any significant support for running on Apple hardware. There's two problems here: 1) QA apparently don't have any Macs, so it's difficult to test this case 2) Policy says that once the go decision has been made, there's no way to revoke it (1) is something that we really need to solve, because it's clearly unreasonable to expect community members to have a test Mac to install every RC. (2) is stranger. Obviously once an image is released, we're not going to be able to recall it, and we have no history of producing updated install images. But right now we're in a window where we haven't officially shipped anything and are saying we can't fix this issue purely because we've written a policy that says we can't. There are workarounds - users can either perform custom partitioning, wipe their disk entirely or install using beta and then upgrade to final. It's not an utter disaster. However, if it had been caught 12 hours earlier, we'd probably have been willing to delay the release to fix it. I don't know that there's a good answer here. It's unfortunate to ship with somewhat broken support for a widespread class of hardware, especially when Fedora's compatibility with that hardware is a unique selling point. But I don't know that it's worth going through the misery of trying to delay things at this point, especially since the US holidays next week seem to be the kind of thing designed to turn any small slip into weeks. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: delays between kernel builds and updates-testing
Am 28.06.2013 17:42, schrieb Kevin Fenzi: On Fri, 28 Jun 2013 17:09:43 +0200 Reindl Harald h.rei...@thelounge.net wrote: which does not explain why 3.9.6 and 3.9.7 was not in updates-testing and 3.9.7 got there today, a week after it was built and after 3.9.8 was built on koji for F17 Only the kernel maintainers can answer that. How about we wait and let them do that? OK If you want to help with this test kernels on the older releases and give appropriate feedback in bohdi for them. this is a conceptional problem in the Fedora infrastructure IMHO, no. Only those builds that maintainers desire to push out as updates are pushed out as updates. There's many reasons why someone would build something but not push it out (yet) IMHO, yes. if i install kernel from koji on several machines and have a option to give karma if it works it would be in any case a useful information for the maintainers which is indepedent from what they desired intentionally Perhaps there was a very nasty bug and they wanted a reporter to confirm. Perhaps they did the build, but discovered some bug in their testing after the build completed then kernel.x86_64 3.9.7-100.fc17 would not have been pusehd to updates-testing a week after build today, henceif the package would have any hint that it is a security-update on koji i would have tested and deployed it days ago, that is why we run test environments for production-servers running Fedora old-stable to not wait for karma of random users which may never happen - but not for each random build with no indication of security-fixes http://koji.fedoraproject.org/koji/buildinfo?buildID=428473 does not have any security hint in the changelog signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: delays between kernel builds and updates-testing
On Fri, Jun 28, 2013 at 12:01 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 28.06.2013 17:42, schrieb Kevin Fenzi: On Fri, 28 Jun 2013 17:09:43 +0200 Reindl Harald h.rei...@thelounge.net wrote: which does not explain why 3.9.6 and 3.9.7 was not in updates-testing and 3.9.7 got there today, a week after it was built and after 3.9.8 was built on koji for F17 Only the kernel maintainers can answer that. How about we wait and let them do that? OK There were no additional major fixes on top of 3.9.5. Given that a 3.9.x kernel has been sitting in updates testing for almost a month now, there seemed to be little point in throwing a new one in that hasn't been tested very well. If you want to help with this test kernels on the older releases and give appropriate feedback in bohdi for them. this is a conceptional problem in the Fedora infrastructure IMHO, no. Only those builds that maintainers desire to push out as updates are pushed out as updates. There's many reasons why someone would build something but not push it out (yet) IMHO, yes. if i install kernel from koji on several machines and have a option to give karma if it works it would be in any case a useful information for the maintainers which is indepedent from what they desired intentionally You can always email us saying it works. Or comment in the bugs the changelog says are fixed. Perhaps there was a very nasty bug and they wanted a reporter to confirm. Perhaps they did the build, but discovered some bug in their testing after the build completed then kernel.x86_64 3.9.7-100.fc17 would not have been pusehd to updates-testing a week after build today, henceif the package would have any hint that it is a security-update on koji i would have tested and deployed it days ago, that is why we run test environments for production-servers running Fedora old-stable to not wait for karma of random users which may never happen - but not for each random build with no indication of security-fixes http://koji.fedoraproject.org/koji/buildinfo?buildID=428473 does not have any security hint in the changelog Because 3.9.6, 3.9.7, and 3.9.8 don't have any security fixes. If you look at the F17 update, the fixes were already in 3.9.5, which was in updates-testing already. The update was edited to use the newer builds. It inherits the update type from whatever the original setting was. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 28 Jun 2013 17:00:40 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: 979205 got filed yesterday, which makes it incredibly difficult to install F19 on Macs while keeping OS X. This is rather frustrating, since Fedora's the only distribution with any significant support for running on Apple hardware. There's two problems here: 1) QA apparently don't have any Macs, so it's difficult to test this case 2) Policy says that once the go decision has been made, there's no way to revoke it (1) is something that we really need to solve, because it's clearly unreasonable to expect community members to have a test Mac to install every RC. (2) is stranger. Obviously once an image is released, we're not going to be able to recall it, and we have no history of producing updated install images. But right now we're in a window where we haven't officially shipped anything and are saying we can't fix this issue purely because we've written a policy that says we can't. It's not strange to me. Once go happens there's a lot of wheels that start in motion: - Press/announcements/scheduling. Things like release day parties, ordering media to give out at events, reviewers in press, etc. - Branched nightly compose is disabled, 0 day updates populated. If we needed to pick things out of updates to re-add to the base repo we would have to reverse this, which is of course possible, but a gigantic hassle, something we have never done before so likely error prone, etc. - Content is staging to mirrors. We could of course tweak this content, but mirrors are expecting it now and may not like having to re-sync large content like isos. Note that a fedora release is not an image. It's a pretty staggering amount of content. ;) and finally the big one: - Say we ground all the wheels to a halt and slipped for this bug. Where to do we draw the line? If someone comes up with a bug at 9:50am on release morning, do we cancel everything? There has to be a point where we say sorry, it's too late and this has been it since it makes sense from a logistic standpoint. Hopefully this makes sense. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: delays between kernel builds and updates-testing
Am 28.06.2013 18:13, schrieb Josh Boyer: if i install kernel from koji on several machines and have a option to give karma if it works it would be in any case a useful information for the maintainers which is indepedent from what they desired intentionally You can always email us saying it works. Or comment in the bugs the changelog says are fixed. OK, if you are well with get a short e-mail what new kernel build works on VMware ESxi as well as HP HP Compaq 8200/8300 i have no problem to do this my setups covers a lot of usecases from web/mailserver up to NAT/firewall/openvpn-routers between corporate networks http://koji.fedoraproject.org/koji/buildinfo?buildID=428473 does not have any security hint in the changelog Because 3.9.6, 3.9.7, and 3.9.8 don't have any security fixes. If you look at the F17 update, the fixes were already in 3.9.5, which was in updates-testing already. The update was edited to use the newer builds. It inherits the update type from whatever the original setting was hm that is a little bit bad, i get usually alarmed with the daily cronjob below if i not see CVE's on the koji changelog, in both cases on a boring evening i start testing often before you know the build has yet finished :-) what would be *really* helpful is a changelog-entry on top of each build security-update yes/no referring to the build before for the same fedora version, this would make it easy to look which package is installed on the production machines and decide if the build can be skipped or not, in any case my two physical machines and testing VMware guests most likely get it [root@buildserver:~]$ cat /scripts/check-updates.sh #!/usr/bin/bash yum_output=`LANG=C; yum --enablerepo=updates-testing -q check-update --security 2 /dev/null` echo $yum_output | xargs | sed 's/ updates//g' | tr -d '\n' BTW: 3.9.8-100.fc17.x86_64 #1 SMP Thu Jun 27 19:19:57 UTC 2013 has passed all tests on top of VMware ESXi and 3.9.8-200.fc18 will hit my homeserver within the next 20 minutes signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 10:25:58AM -0600, Kevin Fenzi wrote: - Say we ground all the wheels to a halt and slipped for this bug. Where to do we draw the line? If someone comes up with a bug at 9:50am on release morning, do we cancel everything? There has to be a point where we say sorry, it's too late and this has been it since it makes sense from a logistic standpoint. If at 9:50am on release morning we discovered that the installer would format all connected drives if the month had two digits, I'd like to think we'd do something about it. It's inevitably going to be a judgement call based on the perceived harm in releasing as is against the harm caused by slipping, just as it is at any other point in the release process. Current policy effectively says There is no issue sufficient to delay release after we've said an image is good, and I don't believe that that's true. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Regexp-Grammars-1.030.tar.gz uploaded to lookaside cache by wfp
A file has been added to the lookaside cache for perl-Regexp-Grammars: a87a0204466d3e833f8e826c3eb75ebf Regexp-Grammars-1.030.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 2013-06-28 at 17:00 +0100, Matthew Garrett wrote: On Thu, Jun 27, 2013 at 07:34:06PM -0400, Jaroslav Reznik wrote: At the Fedora 19 Final Go/No-Go Meeting that just occurred, it was agreed to Go with the Fedora 19 by Fedora QA, development, release engineering and FPM. 979205 got filed yesterday, which makes it incredibly difficult to install F19 on Macs while keeping OS X. This is rather frustrating, since Fedora's the only distribution with any significant support for running on Apple hardware. There's two problems here: 1) QA apparently don't have any Macs, so it's difficult to test this case 2) Policy says that once the go decision has been made, there's no way to revoke it (1) is something that we really need to solve, because it's clearly unreasonable to expect community members to have a test Mac to install every RC. So turns out I was wrong on that: we, (by which I think you mean paid Red Hat QA staff - we certainly have regular testers with Macs, Chris is one of them) do have a UEFI Mac Mini in Brno, we arranged that last year. What we don't have is a test case for Mac dual-boot. This is because it hasn't really been considered to be a release requirement (ever, this release is no different from any previous one). We have a dual-boot with Windows test and explicit criterion: The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows But we do not have anything corresponding for Macs. This was a conscious decision made in the past, not an omission. If we now think it is realistic and worthwhile to support dual boot on Macs we can re-consider that decision, but it would be an explicit policy change, not just rectifying an oversight or something. (I'll note that, quite honestly, I wouldn't consider UEFI dual/multi boot of any kind remotely robust as things stand. It still appears to be very much a work in progress. The only thing that we really have code for that I'd vaguely stand behind is Windows BIOS dual boot.) (2) is stranger. Obviously once an image is released, we're not going to be able to recall it, and we have no history of producing updated install images. But right now we're in a window where we haven't officially shipped anything and are saying we can't fix this issue purely because we've written a policy that says we can't. Well, the policy was presumably not yanked out of thin air. It predates my arrival at RH/Fedora, so I don't know personally the reasoning behind it, but I can guess that a lot of it has to do with release engineering and website logistics. We need to have a definite point of no return in order to do a final stable push, mash, unfreeze the updates repo and stage everything out to mirrors. That's not an overnight operation. I'm not releng so I don't know for sure, but it may well be that at this stage in the game it isn't actually straightforward/possible to 'un-Gold'. There are workarounds - users can either perform custom partitioning, wipe their disk entirely or install using beta and then upgrade to final. It's not an utter disaster. However, if it had been caught 12 hours earlier, we'd probably have been willing to delay the release to fix it. I'm not actually sure that's the case. As I said above, we don't have a release requirement for this and that is at least in part an explicit choice, not an oversight. We explicitly did not consider Mac dual boot a case we wanted to commit to 'supporting' in the past. I'll also note that we haven't _definitely_ confirmed the issue as described yet. Chris is a good tester, but single testers can always get things wrong. I would like it if someone else with a Mac can return it as close to a stock factory configuration as possible and try a Fedora 19 install on the simplest possible path and confirm that they hit the bug. There is another 'workaround' you haven't considered: we can simply build an updates.img that fixes the issue (or works around it, by ditching the commit from 19.13.10 that apparently broke this case), and link to that from the common bugs page and the bug itself. I don't know that there's a good answer here. It's unfortunate to ship with somewhat broken support for a widespread class of hardware, especially when Fedora's compatibility with that hardware is a unique selling point. Well, I'd say _limited_ compatibility. We've had all kinds of bugs in Mac support in, well, pretty much all previous releases too. It's not as if we have a track record of excellent support, we have a track record of 'you can probably kind of make it work if you try hard enough'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
Fedora 19 ARM GO/NO GO meeting minutes
Quick summary from our meeting today- we will be shipping Fedora 19 for ARM on July 2nd. This marks a significant milestone for ARM, being our first release that will ship alongside the primary architectures on day one. Many thanks to those who made this possible. Thanks to those that were able to join us today, for those unable the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-06-28/fedora_arm_19_gono-go.2013-06-28-16.06.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-06-28/fedora_arm_19_gono-go.2013-06-28-16.06.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-06-28/fedora_arm_19_gono-go.2013-06-28-16.06.log.html = #fedora-meeting-1 Meeting = Meeting started by dgilmore at 16:06:36 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-06-28/fedora_arm_19_gono-go.2013-06-28-16.06.log.html . Meeting summary --- * LINK: https://fedoraproject.org/wiki/Category:Fedora_19_ARM_RC3 link to test overview (dgilmore, 16:11:26) * QA status (dgilmore, 16:13:10) * releng status (dgilmore, 16:32:37) * Development status (dgilmore, 16:36:45) * todo (dgilmore, 16:39:44) * LINK: https://fedoraproject.org/wiki/Fedora_ARM_Creator (pwhalen, 16:45:43) * vote is to go (dgilmore, 16:56:18) * stick a fork in it, shes done (dgilmore, 16:56:31) * Dennis to do release announcement (jonmasters, 16:56:34) * Dennis to do release announcement (dgilmore, 16:56:47) * Paul to start page on release instructions, jonmasters to test OMAP (jonmasters, 16:57:02) * Paul to start page on release instructions, jonmasters to test OMAP (pwhalen, 16:58:10) * jonmasters to provide an OMAP3 fix (post-release) sufficient for an OMAP Remix or updated 3.10 images later (jonmasters, 16:58:44) * Release retrospective will be planned for a week or two after release (when Paul and Dennis are back) (jonmasters, 17:01:31) * LINK http://fedoraproject.org/wiki/Fedora_19_ARM_QA_Retrospective Meeting ended at 17:02:36 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * dgilmore (110) * jonmasters (96) * pwhalen (69) * handsome_pirate (21) * masta (9) * zodbot (8) * bconoboy (7) * dmarlin (3) * jdulaney (1) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson awill...@redhat.com wrote: There is another 'workaround' you haven't considered: we can simply build an updates.img that fixes the issue (or works around it, by ditching the commit from 19.13.10 that apparently broke this case), and link to that from the common bugs page and the bug itself. I asked Matthew and Brian about that earlier. It can be done, but most Macs don't have working wireless until after install because b43 and sucky firmware. So any updates.img would likely need to be stuck on a USB key. Something to keep in mind if it gets written up for common bugs. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox in Rawhide is out of date
2013-06-27 20:57, Elio Maldonado Batiz skrev: I brought this up with the nss/nspr team upstream. Kai added a good explanation for them and proposedchanging the naming scheme two use three numbersalwaysas the long term solution. Until that is accepted and implemented upstream option (1) is a good temporary solution. I'm working on testing it right now. I should have it solved by day's end. Thanks for fixing it up Elio, I see it has now landed in today's rawhide compose. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote: On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson awill...@redhat.com wrote: There is another 'workaround' you haven't considered: we can simply build an updates.img that fixes the issue (or works around it, by ditching the commit from 19.13.10 that apparently broke this case), and link to that from the common bugs page and the bug itself. I asked Matthew and Brian about that earlier. It can be done, but most Macs don't have working wireless until after install because b43 and sucky firmware. So any updates.img would likely need to be stuck on a USB key. Something to keep in mind if it gets written up for common bugs. Yee, I just _love_ me some Macs. Thanks; I'll take that into account for commonbugs. When did Macs stop having ethernet ports? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
If at 9:50am on release morning, aliens threatened to blow up the world if we shipped, we'd certainly do something about it. But it would be insane to expect us to *document* that we'd do something about it. IMHO it's perfectly reasonable for documented policy to simply say bugs after this point won't stop a release because there are rational people behind the process to handle exceptional cases, and no amount of imagined example scenarios make the policy any less appropriate. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Thu, Jun 27, 2013 at 11:24:07PM -0700, Adam Williamson wrote: On Thu, 2013-06-27 at 18:41 -0400, Colin Walters wrote: On Thu, 2013-06-27 at 23:38 +0200, Lennart Poettering wrote: Why would you want this? I mean, we rate-limit per-service anyway, so the issue of one app flooding evreything else should be mostly non-existant. And hence, what you are asking for is some policy control about what to delete first, which only really matters if your disk space is very very limited? Would you consider it sane to log say Apache traffic to the journal? If not, then there's still logrotate in the picture, and daemons need to do the whole SIGHUP dance. You can ignore the rest of this message in that case. But if you do, then it would seem fairly sane to me on a medium traffic site to want the ability to have different retention policies for the webserver logs versus other system events like sudo activations or a change of the root password. I'm not entirely sure how this works, but in some sense, journal separates logs *by uid* - if you look in /var/log/journal , there are files for root and files for your uid. If you were logging httpd via the journal, it may be that it'd wind up in a different journal file for the uid httpd was being run as. I haven't checked if you can set rotation policies on a per-uid level. (I'm sure Lennart can explain this more, er, correctly.) Splitting is controlled by SplitMode= Controls whether to split up journal files per user. One of login, uid and none. If login each logged in user will get his own journal files, but systemd user IDs will log into the system journal. If uid any user ID will get his own journal files regardless whether it belongs to a system service or refers to a real logged in user. If none journal files are not split up per-user and all messages are stored in the single system journal. [1] I guess this could be sanely extended to split the logs for some services out even more. Zbyszek [1] http://www.freedesktop.org/software/systemd/man/journald.conf.html#SplitMode= -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2013 01:24 PM, Adam Williamson wrote: On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote: On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson awill...@redhat.com wrote: There is another 'workaround' you haven't considered: we can simply build an updates.img that fixes the issue (or works around it, by ditching the commit from 19.13.10 that apparently broke this case), and link to that from the common bugs page and the bug itself. I asked Matthew and Brian about that earlier. It can be done, but most Macs don't have working wireless until after install because b43 and sucky firmware. So any updates.img would likely need to be stuck on a USB key. Something to keep in mind if it gets written up for common bugs. Yee, I just _love_ me some Macs. Thanks; I'll take that into account for commonbugs. When did Macs stop having ethernet ports? When the MacBook Air became the flagship Mac. I think most MacBook Pro and all desktop models still have one, though. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHNyHgACgkQeiVVYja6o6OnLQCfX/5aCPIlO3oKdMIMjkGl5aqx jYMAnj7tL3QOEnkLGxCnQxuLCNjTHBjK =Qv+k -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 1:31 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2013 01:24 PM, Adam Williamson wrote: On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote: On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson awill...@redhat.com wrote: There is another 'workaround' you haven't considered: we can simply build an updates.img that fixes the issue (or works around it, by ditching the commit from 19.13.10 that apparently broke this case), and link to that from the common bugs page and the bug itself. I asked Matthew and Brian about that earlier. It can be done, but most Macs don't have working wireless until after install because b43 and sucky firmware. So any updates.img would likely need to be stuck on a USB key. Something to keep in mind if it gets written up for common bugs. Yee, I just _love_ me some Macs. Thanks; I'll take that into account for commonbugs. When did Macs stop having ethernet ports? When the MacBook Air became the flagship Mac. I think most MacBook Pro and all desktop models still have one, though. The MacBook Pro I have does not have an ethernet port. It's a 10,2 model. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 2013-06-28 at 13:31 -0400, Stephen Gallagher wrote: On 06/28/2013 01:24 PM, Adam Williamson wrote: On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote: On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson awill...@redhat.com wrote: There is another 'workaround' you haven't considered: we can simply build an updates.img that fixes the issue (or works around it, by ditching the commit from 19.13.10 that apparently broke this case), and link to that from the common bugs page and the bug itself. I asked Matthew and Brian about that earlier. It can be done, but most Macs don't have working wireless until after install because b43 and sucky firmware. So any updates.img would likely need to be stuck on a USB key. Something to keep in mind if it gets written up for common bugs. Yee, I just _love_ me some Macs. Thanks; I'll take that into account for commonbugs. When did Macs stop having ethernet ports? When the MacBook Air became the flagship Mac. It was a genuine question, not a rhetorical 'OMG how can they not have ethernet?!?' one - I was hoping for some specifics. It'll affect the tone of the common bugs entry. I think most MacBook Pro and all desktop models still have one, though. I figured desktops, but wasn't sure about MBPs. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 01:26:52PM -0400, DJ Delorie wrote: If at 9:50am on release morning, aliens threatened to blow up the world if we shipped, we'd certainly do something about it. But it would be insane to expect us to *document* that we'd do something about it. Why? Beyond this point the release will only be delayed if an issue is discovered that is deemed of exceptional importance is a perfectly reasonable thing to document. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 6:33 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-06-28 at 13:31 -0400, Stephen Gallagher wrote: On 06/28/2013 01:24 PM, Adam Williamson wrote: On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote: On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson awill...@redhat.com wrote: There is another 'workaround' you haven't considered: we can simply build an updates.img that fixes the issue (or works around it, by ditching the commit from 19.13.10 that apparently broke this case), and link to that from the common bugs page and the bug itself. I asked Matthew and Brian about that earlier. It can be done, but most Macs don't have working wireless until after install because b43 and sucky firmware. So any updates.img would likely need to be stuck on a USB key. Something to keep in mind if it gets written up for common bugs. Yee, I just _love_ me some Macs. Thanks; I'll take that into account for commonbugs. When did Macs stop having ethernet ports? When the MacBook Air became the flagship Mac. It was a genuine question, not a rhetorical 'OMG how can they not have ethernet?!?' one - I was hoping for some specifics. It'll affect the tone of the common bugs entry. I think most MacBook Pro and all desktop models still have one, though. I figured desktops, but wasn't sure about MBPs. Thanks. I don't think any of the thunderbolt equipped MBPs (or maybe the later ones) have them. The thunderbolt ethernet adapters apparently work if you plug them in before you power them on and presumably all the usb ethernet adapters would work as an option. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/28/2013 01:33 PM, Adam Williamson wrote: On Fri, 2013-06-28 at 13:31 -0400, Stephen Gallagher wrote: On 06/28/2013 01:24 PM, Adam Williamson wrote: On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote: On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson awill...@redhat.com wrote: There is another 'workaround' you haven't considered: we can simply build an updates.img that fixes the issue (or works around it, by ditching the commit from 19.13.10 that apparently broke this case), and link to that from the common bugs page and the bug itself. I asked Matthew and Brian about that earlier. It can be done, but most Macs don't have working wireless until after install because b43 and sucky firmware. So any updates.img would likely need to be stuck on a USB key. Something to keep in mind if it gets written up for common bugs. Yee, I just _love_ me some Macs. Thanks; I'll take that into account for commonbugs. When did Macs stop having ethernet ports? When the MacBook Air became the flagship Mac. It was a genuine question, not a rhetorical 'OMG how can they not have ethernet?!?' one - I was hoping for some specifics. It'll affect the tone of the common bugs entry. I think most MacBook Pro and all desktop models still have one, though. I figured desktops, but wasn't sure about MBPs. Thanks. Actually, looks like the Retina Display models don't include ethernet either (they have an ethernet-to-thunderbolt adapter for sale instead). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHNymgACgkQeiVVYja6o6P8TgCggYxRYaqsH5zz/OlFrw3M89+9 IbUAnRBwd/OQGcfBO0aUysKycDoKvtMU =ysLq -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 10:13:15AM -0700, Adam Williamson wrote: Well, I'd say _limited_ compatibility. We've had all kinds of bugs in Mac support in, well, pretty much all previous releases too. It's not as if we have a track record of excellent support, we have a track record of 'you can probably kind of make it work if you try hard enough'. Since F17 we've had a track record of It'll work fine, as long as you don't hit a kernel bug. Which is exactly where we are with every other platform. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 2013-06-28 at 18:40 +0100, Matthew Garrett wrote: On Fri, Jun 28, 2013 at 10:13:15AM -0700, Adam Williamson wrote: Well, I'd say _limited_ compatibility. We've had all kinds of bugs in Mac support in, well, pretty much all previous releases too. It's not as if we have a track record of excellent support, we have a track record of 'you can probably kind of make it work if you try hard enough'. Since F17 we've had a track record of It'll work fine, as long as you don't hit a kernel bug. Which is exactly where we are with every other platform. With all respect, the bug reports and blogs I've read would not lead me to support that assertion. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 ARM GO/NO GO meeting minutes
On Fri, Jun 28, 2013 at 01:18:59PM -0400, Paul Whalen wrote: Quick summary from our meeting today- we will be shipping Fedora 19 for ARM on July 2nd. This marks a significant milestone for ARM, being our first release that will ship alongside the primary architectures on day one. Many thanks to those who made this possible. Congratulations on getting this far! Is there documentation of the delta between ARM and primary architectures? I'm thinking things like no llvmpipe/clang or limited interactive Anaconda support. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 10:38 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Jun 28, 2013 at 01:26:52PM -0400, DJ Delorie wrote: If at 9:50am on release morning, aliens threatened to blow up the world if we shipped, we'd certainly do something about it. But it would be insane to expect us to *document* that we'd do something about it. Why? Beyond this point the release will only be delayed if an issue is discovered that is deemed of exceptional importance is a perfectly reasonable thing to document. Agreed. If added, and the end user demanded something unreasonable, this would cover us and justify a delay. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 10:43:33AM -0700, Adam Williamson wrote: With all respect, the bug reports and blogs I've read would not lead me to support that assertion. With all respect, bug numbers. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 28 Jun 2013 10:46:51 -0700 Richard Vickery richard.vicker...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:38 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Jun 28, 2013 at 01:26:52PM -0400, DJ Delorie wrote: If at 9:50am on release morning, aliens threatened to blow up the world if we shipped, we'd certainly do something about it. But it would be insane to expect us to *document* that we'd do something about it. Why? Beyond this point the release will only be delayed if an issue is discovered that is deemed of exceptional importance is a perfectly reasonable thing to document. Agreed. If added, and the end user demanded something unreasonable, this would cover us and justify a delay. Well, the problem is then someone would ask What is exceptional ? So, we would need some process to determine that. Based on this line you could also ask what we would do if some horrible deadly bug was found _after_ public release. Should we remove images? Disable mirrormanager? Repin the release? 19.1? 20? Anyhow, if you would like to amend the release process, feel free to write up a proposal. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Jun 28, 2013, at 10:26 AM, DJ Delorie d...@redhat.com wrote: If at 9:50am on release morning, aliens threatened to blow up the world if we shipped, we'd certainly do something about it. So what you're saying is that you negotiate with terrorists? :-p On a more serious note, though it hasn't been a focus before, dual boot is probably a decent design goal for the next iteration. I'd probably not hold back this release at this point in time, not that anybody asked me. --Corey -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libgd breakage
2013/6/28 Volker Fröhlich volke...@gmx.at: On 27/06/13 17:31, Orion Poplawski wrote: On 06/26/2013 08:01 AM, Volker Fröhlich wrote: GDAL is currently broken because it needs a rebuild for Poppler, but the Texlive build is broken, as far as I can see. texlive has now been rebuilt. We've got a working GDAL build again. Almost there, but still cannot generate chroot in mock. DEBUG util.py:264: Error: Package: gnuplot-4.6.2-2.fc20.x86_64 (build) DEBUG util.py:264: Requires: libgd.so.2()(64bit) Also cannot update my rawhide computer (yum loops forever if I run with --skip-broken), after yum erase sagemath gnuplot still fails: Error: Package: libsss_sudo-1.10.0-7.fc20.beta1.x86_64 (@rawhide) Requires: sssd = 1.10.0-7.fc20.beta1 Removing: sssd-1.10.0-7.fc20.beta1.x86_64 (@rawhide) sssd = 1.10.0-7.fc20.beta1 Updated By: sssd-1.10.0-13.fc20.x86_64 (rawhide) sssd = 1.10.0-13.fc20 Thanks, Paulo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On 06/28/2013 01:31 PM, Stephen Gallagher wrote: Yee, I just _love_ me some Macs. Thanks; I'll take that into account for commonbugs. When did Macs stop having ethernet ports? When the MacBook Air became the flagship Mac. We just got a MacBook Air and it came with a Thunderbolt pigtail Ethernet port: http://cdn.arstechnica.net/wp-content/uploads/2012/06/tbge.jpg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
So what you're saying is that you negotiate with terrorists? :-p Anyone else want to negotiate? (sorry, couldn't resist ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Jun 28, 2013, at 10:39 AM, Peter Robinson pbrobin...@gmail.com wrote: I don't think any of the thunderbolt equipped MBPs (or maybe the later ones) have them. The thunderbolt ethernet adapters apparently work if you plug them in before you power them on and presumably all the usb ethernet adapters would work as an option. To be slightly more specific as a Mac laptop user, all of their currently shipping laptops omit an onboard Ethernet port, with the exception of their non-retina equipped MacBook Pros. That specific line is widely considered to be legacy, and expected to be discontinued. --Corey -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) said: Splitting is controlled by SplitMode= Controls whether to split up journal files per user. One of login, uid and none. If login each logged in user will get his own journal files, but systemd user IDs will log into the system journal. If uid any user ID will get his own journal files regardless whether it belongs to a system service or refers to a real logged in user. If none journal files are not split up per-user and all messages are stored in the single system journal. [1] I guess this could be sanely extended to split the logs for some services out even more. Presumably you'd want to do them by either service name or by slice? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Jun 28, 2013, at 11:14 AM, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 06/28/2013 01:31 PM, Stephen Gallagher wrote: Yee, I just _love_ me some Macs. Thanks; I'll take that into account for commonbugs. When did Macs stop having ethernet ports? When the MacBook Air became the flagship Mac. We just got a MacBook Air and it came with a Thunderbolt pigtail Ethernet port: http://cdn.arstechnica.net/wp-content/uploads/2012/06/tbge.jpg Those are ~$30 a pop, and don't ship with the laptop. Thus we can't count on a Mac laptop user having one. --Corey -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Fri, Jun 28, 2013 at 07:27:30PM +0200, Zbigniew Jędrzejewski-Szmek wrote: Splitting is controlled by SplitMode= Controls whether to split up journal files per user. One of login, uid and none. If login each logged in user will get his own journal files, but systemd user IDs will log into the system journal. If uid any user ID will get his own journal files regardless whether it belongs to a system service or refers to a real logged in user. If none journal files are not split up per-user and all messages are stored in the single system journal. [1] I guess this could be sanely extended to split the logs for some services out even more. Maybe we should make uid the default? What are the drawbacks? It seems like this would allow sysadmins the ability to do some more flexible things with log access without much effort. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Fri, Jun 28, 2013 at 02:46:25PM -0400, Matthew Miller wrote: On Fri, Jun 28, 2013 at 07:27:30PM +0200, Zbigniew Jędrzejewski-Szmek wrote: Splitting is controlled by SplitMode= Controls whether to split up journal files per user. One of login, uid and none. If login each logged in user will get his own journal files, but systemd user IDs will log into the system journal. If uid any user ID will get his own journal files regardless whether it belongs to a system service or refers to a real logged in user. If none journal files are not split up per-user and all messages are stored in the single system journal. [1] I guess this could be sanely extended to split the logs for some services out even more. Maybe we should make uid the default? What are the drawbacks? It seems like this would allow sysadmins the ability to do some more flexible things with log access without much effort. 'uid' as default doesn't make sense, at least with the current way of accesing logs. It is really nice to be able to view messages about a service interleaved from various sources. Now when you say 'journalctl -u httpd', you get logs from the processes in the httpd.service, but also messages from systemd about this service, and possibly information about coredumps and hopefully, soon, messages from setroubleshoot. With 'uid', and looking only at one file, you'd get only the first kind. With user messages the situation is better, because the messages from outside are less interesting, so the login split works mostly ok. Also, there's currently only one policy for rotation, so journald will not treat logs for one service specially. It would be simple to add a cron job which removes those files, but it is better to have such functionality directly in journald. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: and we have no history of producing updated install images. Is there *any* reason why we can't? This sounds like a reasonable thing to do. Just because we have not done it in the past is not a reason not to. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 6:25 PM, Kevin Fenzi ke...@scrye.com wrote: it makes sense from a logistic standpoint. But from any other POV it makes no sense. There is no reason why we cannot produce and ship updated images if we find a bug that is important enough. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 2013-06-28 at 22:13 +0200, drago01 wrote: On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: and we have no history of producing updated install images. Is there *any* reason why we can't? This sounds like a reasonable thing to do. Just because we have not done it in the past is not a reason not to. Well unless a bunch more people want to volunteer to test them, you'll have a flaming-torch-and-pitchfork mob of QA people on your hands. =) We already spend 8 months of the year on a constant test/rebuild/test cycle; we get 2 months each cycle to do...pretty much everything else. If we start trying to ship N.1 images we will likely be spending about 8 months of every 6 month cycle on release validation (if you see what I mean). Count me out. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 28 Jun 2013 22:14:51 +0200 drago01 drag...@gmail.com wrote: On Fri, Jun 28, 2013 at 6:25 PM, Kevin Fenzi ke...@scrye.com wrote: it makes sense from a logistic standpoint. But from any other POV it makes no sense. There is no reason why we cannot produce and ship updated images if we find a bug that is important enough. Sure, we could release every day given enough resources and desire to do so. I think we are very far afield. :) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Fri, Jun 28, 2013 at 09:48:58PM +0200, Zbigniew Jędrzejewski-Szmek wrote: 'uid' as default doesn't make sense, at least with the current way of accesing logs. It is really nice to be able to view messages about a service interleaved from various sources. Now when you say 'journalctl -u httpd', you get logs from the processes in the httpd.service, but also messages from systemd about this service, and possibly information about coredumps and hopefully, soon, messages from setroubleshoot. With 'uid', and looking only at one file, you'd get only the first kind. But many cases for accesssing HTTP logs don't need that kind of mixed information. The service is running fine, but people or programs may want to look for information about visitors, hits, referrers, etc., etc. The sysadmin wants the unified view, but the web admin just needs http logs. Never mind the basic principle of least necessary privilege -- all that other stuff is just noise. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 10:32 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 28 Jun 2013 22:14:51 +0200 drago01 drag...@gmail.com wrote: On Fri, Jun 28, 2013 at 6:25 PM, Kevin Fenzi ke...@scrye.com wrote: it makes sense from a logistic standpoint. But from any other POV it makes no sense. There is no reason why we cannot produce and ship updated images if we find a bug that is important enough. Sure, we could release every day given enough resources and desire to do so. there is a difference between every day and when there is an urgent issue. So this is really a non argument. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 28 Jun 2013 22:13:09 +0200 drago01 drag...@gmail.com wrote: On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: and we have no history of producing updated install images. Is there *any* reason why we can't? This sounds like a reasonable thing to do. Just because we have not done it in the past is not a reason not to. Sure we could. We would need to: * Have some way to freeze things so we could stablize for the release. * Anaconda team willing to work on updated release + next release at the same time. * releng folks avilable to compose stuff. * QA folks available to run through all the release tests. * Mirrors willing to have another pile of release bits * Marketing/press folks willing to put together stuff for the release * Docs willing to update any release notes, etc. * Any additional tooling needed if we call this 19.1 or something. So, all this is doable, it's just a lot of resources to try and move around, so personally I would only be willing to go down this road if it was something really really really severe, and it would need buy in from stakeholders. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 28 Jun 2013 22:13:09 +0200 drago01 drag...@gmail.com wrote: On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: and we have no history of producing updated install images. Is there *any* reason why we can't? This sounds like a reasonable thing to do. Just because we have not done it in the past is not a reason not to. Sure we could. We would need to: * Have some way to freeze things so we could stablize for the release. We should use the GA package set + the fixed build not get all updates in. It is to fix one bug not to create updated images. * Anaconda team willing to work on updated release + next release at the same time. The anaconda team will have to fix the bug anyway. Unless the bug requires lots of changes should be easy to backport (cherry-pick) assuming an anaconda bug is the reason why we need a release. Otherwise they don't have to do anything. * releng folks avilable to compose stuff. * QA folks available to run through all the release tests. Both sound doable. * Mirrors willing to have another pile of release bits * Marketing/press folks willing to put together stuff for the release * Docs willing to update any release notes, etc. * Any additional tooling needed if we call this 19.1 or something. Do we have to bump the release number? We can just update the images and let mirrors resync. So, all this is doable, it's just a lot of resources to try and move around, Sure it needs work but do we should care about quality of what we ship to users. If we fucked up we should try to fix it. Not just say sorry that happened see you 6-8 months. so personally I would only be willing to go down this road if it was something really really really severe, That's the whole point. We should do it only if we have to. But not rule it out because we have never done that. and it would need buy in from stakeholders. Given that we don't point guns at people in a (mostly) volunteer driven project ... this is a given. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
Hi, - Original Message - From: Lennart Poettering mzerq...@0pointer.de Subject: Re: logrotate(8) and copytruncate as default journald is the only writer, it doesn't need locking. The changes it does are done in a way so that concurrent readers will either see the changes or not, but never half-written changes. I see. How is that done? Does journald also renames the current file and creates a new one and continues writing to that new file?? I'm asking because, if not, then journald could also suffer from the same buffering issue that kernel seems to do with locking. Ie. As the file size grows copy-truncate takes time, kernel is unable to buffer all the writes that happen during that time, so it starts dropping a few, which results in data loss. Also note that locking on Linux is seriously broken. You can get a lock on any file you can read, thus you can freeze everybody else who might want a lock. Or in other words: if a logging daemon takes a lock on its lock files, then you can use this to make that service freeze forever. Yeah, I realised that. I posted a small script earlier in this thread. With locking, you start seeing data loss as the file size grows = 2MB. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On 28 June 2013 14:43, drago01 drag...@gmail.com wrote: On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 28 Jun 2013 22:13:09 +0200 drago01 drag...@gmail.com wrote: * Mirrors willing to have another pile of release bits * Marketing/press folks willing to put together stuff for the release * Docs willing to update any release notes, etc. * Any additional tooling needed if we call this 19.1 or something. Do we have to bump the release number? We can just update the images and let mirrors resync. In the far past when this was discussed, it was expensive for multiple reasons: 1) Mirrors may not remirror static content. They do it once and then focus on directories that they know change a lot. It cuts down their network costs in a number of ways. So you end up with mirrors with one iso and others with other isos. 2) People get a version of ISO x and then compare the MD5/signature with the updated version and then start wondering if the website has been hacked. Emails on this can show up years and years later when no one remembers that the ISO was replaced for some reason. We still get requests and people using Fedora Core 6 images they just got.. All of these end up costing more in time and electrons than just spinning up updates.img or a .x version. Not counting the usual fight that has happened in the past for why isn't my update not in the respin? .. especially when some argument can be made that it is causing some sort of installation issue from my icons aren't right on this box to that selinux policy would help make out fo the box experience better. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 2013-06-28 at 22:43 +0200, drago01 wrote: On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 28 Jun 2013 22:13:09 +0200 drago01 drag...@gmail.com wrote: On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: and we have no history of producing updated install images. Is there *any* reason why we can't? This sounds like a reasonable thing to do. Just because we have not done it in the past is not a reason not to. Sure we could. We would need to: * Have some way to freeze things so we could stablize for the release. We should use the GA package set + the fixed build not get all updates in. It is to fix one bug not to create updated images. I think there's some confusion here. You now actually seem to be talking about the specific question of producing an updated install image one time, for this one issue, but at first it seemed like you were advocating it as The New Way Forward. Assuming we find a single simple change that Fixes Mac UEFI Dual Boot in anaconda, then from a purely technical standpoint, yes, we could theoretically throw together a boot ISO and DVD with the fix in quite easily. All it'd need would be a new build of anaconda with only that fix, and someone to run pungi a couple of times. Given the apparent constraints on network access on Macs it might even make sense to do that in this particular case, if someone wants to spend the time on it. The way I'd envisage that happening, though, is that we stick them up pretty unofficially with a 'this is an image we think might install better on Macs, use it if you like' label on it. I definitely wouldn't want to go around sounding trumpets and calling it Fedora 19.1. Something altogether less official and more low key seems appropriate. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum groupinstall development-tools FAILS
FChE, On 2013-06-29 01:24, f...@redhat.com wrote: Philip Rhoades p...@pricom.com.au writes: [...] yum --exclude=systemtap-sdt-devel* groupinstall development-tools still gives the same errors . . How about a yum update systemtap\* first? That did it! - Good to remember . . Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: p...@pricom.com.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Jun 28, 2013, at 10:39 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Jun 28, 2013 at 10:25:58AM -0600, Kevin Fenzi wrote: - Say we ground all the wheels to a halt and slipped for this bug. Where to do we draw the line? If someone comes up with a bug at 9:50am on release morning, do we cancel everything? There has to be a point where we say sorry, it's too late and this has been it since it makes sense from a logistic standpoint. If at 9:50am on release morning we discovered that the installer would format all connected drives if the month had two digits, I'd like to think we'd do something about it. It's inevitably going to be a judgement call based on the perceived harm in releasing as is against the harm caused by slipping, just as it is at any other point in the release process. Current policy effectively says There is no issue sufficient to delay release after we've said an image is good, and I don't believe that that's true. One possible solution is either more padding (time) between any RC release and go/no-go; or if certain listed packages, like anaconda, pykickstart, blivet, etc. are touched in even a seemingly trivial way, then the full QA test matrix has to be retested. Maybe that's already implicitly the case, but I don't know if it's a rule. But what definitely isn't the case is, Macs are still not officially supported by QA for blocker status for Mac specific major bugs. If a Mac only bug comes up, block status is rejected on the basis that too few people will experience the bug. So before I'd suggest holding up Fedora 19, I think Macs need to have a promoted hardware status. Something not totally dissimilar happened for Fedora 18 that was also a problem for Macs. That's bug 893839 Mac EFI from DVD and LiveCD ISO burned to actual DVD media results in grub prompt, no boot. I didn't find that until final, definitely too late. But the final release series of RC's happen very quickly, and any allowed change is by definition significant (i.e. necessary) or it simply wouldn't happen, but that also makes the change higher risk than other changes. So I think more time padding is needed between an RC and go/nogo. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Jun 28, 2013, at 11:39 AM, Peter Robinson pbrobin...@gmail.com wrote: I don't think any of the thunderbolt equipped MBPs (or maybe the later ones) have them. The thunderbolt ethernet adapters apparently work if you plug them in before you power them on and presumably all the usb ethernet adapters would work as an option. I think the rule of thumb is if it has one Thunderbolt port and isn't an Air, it has ethernet. If it has two Thunderbolt ports (starting with the late 2012 MBP models), they don't have ethernet. I have a 2011 Thunderbolt MBP and it does have ethernet. In any case the Air is sufficiently popular in and out of hard core Mac circles that it'd need to be taken into account for common bugs. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, 2013-06-28 at 15:42 -0600, Chris Murphy wrote: But the final release series of RC's happen very quickly, and any allowed change is by definition significant (i.e. necessary) or it simply wouldn't happen, but that also makes the change higher risk than other changes. So I think more time padding is needed between an RC and go/nogo. I think you may be labouring under a bit of a misapprehension about what should be tested, here. The distinction between a TC and an RC is not large. An RC can only happen after freeze and must have all blockers fixed: if a build after freeze doesn't have all blockers addressed, we call it a TC. We have gotten better at finding blockers earlier in recent releases. What this means is that we're doing fewer but _better_ RCs. Back around F14 or F15, our first 'RC' build was pretty much a joke; there was never any chance it was actually going to get released. We'd find five blockers in it straight away. I think in the last few release cycles, though, we've actually released RC1 or RC2 several times. I don't really see there being some big distinction between TCs and RCs. If you want to make sure some workflow that's important to you is going to work it's really a good idea to follow the process from TC1, there is no mileage in jumping in at RC1, that's too late. (Never mind the people who, every release, seem to jump in and start testing on the day we do go/no-go and then kick up a fuss about whatever they find...not you, but it does seem to happen). That doesn't quite apply to this specific case, as it happens, but it's an important point to make. Getting down to specifics: the change that we believe broke this - trying to re-use an existing EFI system partition if one is present instead of always creating a new one - went into anaconda 19.30.10. TC6 had 19.30.9, RC1 had 19.30.11; 19.30.10 probably only went into smoke test builds and we found some problem which necessitated 19.30.11. RC1 came out very early Tuesday morning (06-25) (2am Eastern time). If we assume this had been a blocker bug (which I still think it probably wasn't), that gave us about...62 hours to catch it before the sign-off happened. That is a pretty short timeframe, indeed. If we want to identify one specific Thing That Went Wrong here, I would say it's that we probably shouldn't have taken a moderately significant behaviour change as late as that. So let's look at that in a bit more detail: https://bugzilla.redhat.com/show_bug.cgi?id=974543 is the bug that prompted this change. It was filed on 06-14 (though we'd been aware of the behaviour for rather longer). It was proposed as a freeze exception issue by bcl (anaconda developer) on 06-17: that effectively means anaconda team was of the opinion that they wanted this change to go in. It was reviewed for freeze exception status on 06-19. The log of the review meeting is at http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-19/f19final-blocker-review-7.2013-06-19-16.01.log.txt . Here are the relevant bits extracted, since it's very short: 18:53:38 adamw https://bugzilla.redhat.com/show_bug.cgi?id=974543 18:54:20 Viking-Ice dances on the limit of blocker 18:56:37 kparal but we should definitely vote on 974543 18:56:48 kparal it's proposed and patches are ready 18:57:09 adamw +1 on 974543 18:57:20 jreznik +1 FE for 974543, seems like bcl wants this one 18:57:59 tflink #topic (974543) Anaconda is always creating new efi system partition 18:58:02 tflink #link https://bugzilla.redhat.com/show_bug.cgi?id=974543 18:58:04 tflink #info Proposed Freeze Exceptions, anaconda, NEW 18:58:10 adamw tflink: the patches are not sent to anaconda-devel-list so technically not 'post'ed 18:58:11 adamw +1 18:58:20 kparal +1 FE 18:58:20 adamw this is completely wrong behaviour and ought to be fixed 18:58:27 nirik +1 FE 18:58:31 Viking-Ice +1 18:58:35 dgilmore +1 FE 18:58:36 jreznik +1 FE 18:59:12 adamw shame to put it in this late, but otoh our 'multiboot uefi' story has never worked very well so unlikely to maek things worse 18:59:32 tflink proposed #agreed 974543 - AcceptedFreezeException - This behavior of creating new EFI partitions is not correct and should be fixed. A tested fix would be considered past freeze 18:59:33 adamw at some point we're going to run into the problem of what to do if there isn't enough space in the esp but we'll burn that bridge when we get to it 18:59:33 adamw ack 18:59:49 jreznik ack 18:59:57 nirik ack 18:59:59 Viking-Ice ack 18:59:59 tflink #agreed 974543 - AcceptedFreezeException - This behavior of creating new EFI partitions is not correct and should be fixed. A tested fix would be considered past freeze 19:00:00 handsome_pirate ack 19:00:20 kparal adamw: the files are very small, currently So it sailed through review with +1s from four QA folks (myself, Kamil, Tim (implied) and Johann), one from releng (dgilmore) and one from the program manager (jreznik). As has often been the case lately, no-one outside of those
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Fri, Jun 28, 2013 at 11:16 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-06-28 at 22:43 +0200, drago01 wrote: On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 28 Jun 2013 22:13:09 +0200 drago01 drag...@gmail.com wrote: On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: and we have no history of producing updated install images. Is there *any* reason why we can't? This sounds like a reasonable thing to do. Just because we have not done it in the past is not a reason not to. Sure we could. We would need to: * Have some way to freeze things so we could stablize for the release. We should use the GA package set + the fixed build not get all updates in. It is to fix one bug not to create updated images. I think there's some confusion here. You now actually seem to be talking about the specific question of producing an updated install image one time, for this one issue, but at first it seemed like you were advocating it as The New Way Forward. What I am saying is that for this particalur issue we should do it once we have a fix. It does not have to be 19.1 or any other fancy thing just provide something. *AND* leave this option open for future release i.e if we have found an issue that should have been fixed before release and that cannot be fixed by an update we should consider doing this again (decide on case by case basis). We should not rule it out just because we have never done it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Sat, 2013-06-29 at 00:24 +0200, drago01 wrote: On Fri, Jun 28, 2013 at 11:16 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-06-28 at 22:43 +0200, drago01 wrote: On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 28 Jun 2013 22:13:09 +0200 drago01 drag...@gmail.com wrote: On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: and we have no history of producing updated install images. Is there *any* reason why we can't? This sounds like a reasonable thing to do. Just because we have not done it in the past is not a reason not to. Sure we could. We would need to: * Have some way to freeze things so we could stablize for the release. We should use the GA package set + the fixed build not get all updates in. It is to fix one bug not to create updated images. I think there's some confusion here. You now actually seem to be talking about the specific question of producing an updated install image one time, for this one issue, but at first it seemed like you were advocating it as The New Way Forward. What I am saying is that for this particalur issue we should do it once we have a fix. It does not have to be 19.1 or any other fancy thing just provide something. *AND* leave this option open for future release i.e if we have found an issue that should have been fixed before release and that cannot be fixed by an update we should consider doing this again (decide on case by case basis). We should not rule it out just because we have never done it. What we rule out is doing big official .1 builds. We have done various semi-official post-release workarounds for awkward bugs in the past, along the lines of what we're discussing here. special boot.isos showing up in people's fedorapeople.org directories are not unknown. updates.img links in the commonbugs pages are fairly frequent. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libgd breakage
On Fri, 2013-06-28 at 15:14 -0300, Paulo César Pereira de Andrade wrote: 2013/6/28 Volker Fröhlich volke...@gmx.at: On 27/06/13 17:31, Orion Poplawski wrote: On 06/26/2013 08:01 AM, Volker Fröhlich wrote: GDAL is currently broken because it needs a rebuild for Poppler, but the Texlive build is broken, as far as I can see. texlive has now been rebuilt. We've got a working GDAL build again. Almost there, but still cannot generate chroot in mock. DEBUG util.py:264: Error: Package: gnuplot-4.6.2-2.fc20.x86_64 (build) DEBUG util.py:264: Requires: libgd.so.2()(64bit) gnuplot appears to be failing on some sort of texlive-related nonsense: Execute script `gnuplot.lg' /usr/bin/t4ht: line 2: -f/gnuplot: No such file or directory /usr/bin/t4ht: line 3: -f/gnuplot: No such file or directory /usr/bin/t4ht: line 4: -f/gnuplot: No such file or directory --- error --- improper command line and then it just appears to loop over the tex4ht usage message forever and ever. I don't know if the error is in texlive-tex4ht-bin (which provides /usr/bin/t4ht and /usr/bin/tex4ht), or in how gnuplot is calling it. (But I don't have time to figure out that crap, so I'm just going to yum remove gnuplot...) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Fri, 28.06.13 14:46, Matthew Miller (mat...@fedoraproject.org) wrote: On Fri, Jun 28, 2013 at 07:27:30PM +0200, Zbigniew Jędrzejewski-Szmek wrote: Splitting is controlled by SplitMode= Controls whether to split up journal files per user. One of login, uid and none. If login each logged in user will get his own journal files, but systemd user IDs will log into the system journal. If uid any user ID will get his own journal files regardless whether it belongs to a system service or refers to a real logged in user. If none journal files are not split up per-user and all messages are stored in the single system journal. [1] I guess this could be sanely extended to split the logs for some services out even more. Maybe we should make uid the default? What are the drawbacks? It seems like this would allow sysadmins the ability to do some more flexible things with log access without much effort. No. The theory behind the journal is to have everything in one place, in one centralized, comprehensive dataset, and then apply filters on it *when reading it* to see just the bits of it you are interested in. We made an exception to this only for login users, so that we can just reuse normal Unix file system access controls to give them access to their own files without giving them access to anything else. There is no benefit on its own in splitting things up, that simply makes things slower (as the complexity of interleaving journal files grows O(n) with n being the number of journal files) and bigger (as within unit files the same message fields are only stored once and henceforth referenced just by their offset, the effect of which becomes nil if you start anew too often). To make this clear: the journal is *not* supposed to do everything possibly anybody could ever think about. No. It's supposed to just work, make the best of its situation and have only limited knobs to change, for the stuff that really makes sense in major usecases. For everything else you have rsyslog and ElasticSearch and whatnot. They embed programming languages in their configuration files and that's OK for them. For journald its not. We will not split up journal files just for the sake of splitting them up. We care about usecases. And stuff like do some more flexible things is not a usecase. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Fri, 28.06.13 16:33, Matthew Miller (mat...@fedoraproject.org) wrote: On Fri, Jun 28, 2013 at 09:48:58PM +0200, Zbigniew Jędrzejewski-Szmek wrote: 'uid' as default doesn't make sense, at least with the current way of accesing logs. It is really nice to be able to view messages about a service interleaved from various sources. Now when you say 'journalctl -u httpd', you get logs from the processes in the httpd.service, but also messages from systemd about this service, and possibly information about coredumps and hopefully, soon, messages from setroubleshoot. With 'uid', and looking only at one file, you'd get only the first kind. But many cases for accesssing HTTP logs don't need that kind of mixed information. The service is running fine, but people or programs may want to look for information about visitors, hits, referrers, etc., etc. The sysadmin wants the unified view, but the web admin just needs http logs. Never mind the basic principle of least necessary privilege -- all that other stuff is just noise. That's why we are so strong on filtering the dataset when you look at it. May I recommend watching this video? https://www.youtube.com/watch?v=i4CACB7paLc if you want apache's logs, then run journalctl -u httpd... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
More unhelpful update descriptions
There still seems to be an issue with the update descriptions that we present in PackageKit. A lot of people just write update to version x.y.z which is not great, but a whole lot better than some of the ones we've been seeing recently. For example, from two updates I got today: * Not tested locally yet, I need to spin back up a Fedora 18 VM. * Here is where you give an explanation of your update. Now the first one is obviously a one-off mistake, but had the update been checked over just once it would have been caught. The placeholder one is a big recurring problem, though: it seems to show up at least every week or so, which is not OK. And once, about two months ago -- I really should have complained then and not now -- an update was pushed where the text displayed in PackageKit was something along the lines of why do I have to describe my update here when I've already filled out the RPM changelog. I wish it was a joke, but something like that was actually pushed as the description of a F18 update presented to every user who glances over the updates We need written policy on update descriptions, since despite the last discussion on this list [1], poor update descriptions continue to blemish the otherwise-professional image of the distro. A starting point suggestion: Every update should have at least a one sentence description. If the update is not worth writing one sentence about, it is not worth pushing out. Happy Friday, Michael Catanzaro [1] https://lists.fedoraproject.org/pipermail/devel/2013-March/179655.html signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Jun 28, 2013, at 4:20 PM, Adam Williamson awill...@redhat.com wrote: I think you may be labouring under a bit of a misapprehension about what should be tested, here. The distinction between a TC and an RC is not large. An RC can only happen after freeze and must have all blockers fixed: if a build after freeze doesn't have all blockers addressed, we call it a TC. The distinction between TC and RC is large in that an RC1 *could* be final release. And since this particular bug wasn't in TC6 but was in the very next build, RC1, I think that's consistent with suggesting more time between an RC and a go/no-go. I'm not saying e.g. maybe there shouldn't be freeze exception fixes in RCs. Just a bit more time when certain packages are touched. Although even better than that would be more recruitment of Mac users to do installation testing, so that it's possible to get installation tests done for at least RC1s. I tested it in a VM, foolishly not testing it on baremetal. RC2 hit, and I missed that since RC3 came soon after and immediately tested that on baremetal. But between RC3 and go/no-go was a matter of hours. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 2013-06-28 17:44, Michael Catanzaro wrote: There still seems to be an issue with the update descriptions that we present in PackageKit. A lot of people just write update to version x.y.z which is not great, but a whole lot better than some of the ones we've been seeing recently. For example, from two updates I got today: * Not tested locally yet, I need to spin back up a Fedora 18 VM. * Here is where you give an explanation of your update. Now the first one is obviously a one-off mistake, but had the update been checked over just once it would have been caught. The placeholder one is a big recurring problem, though: it seems to show up at least every week or so, which is not OK. And once, about two months ago -- I really should have complained then and not now -- an update was pushed where the text displayed in PackageKit was something along the lines of why do I have to describe my update here when I've already filled out the RPM changelog. I wish it was a joke, but something like that was actually pushed as the description of a F18 update presented to every user who glances over the updates We need written policy on update descriptions, since despite the last discussion on this list [1], poor update descriptions continue to blemish the otherwise-professional image of the distro. A starting point suggestion: Every update should have at least a one sentence description. If the update is not worth writing one sentence about, it is not worth pushing out. I've suggested before that Bodhi should reject any update with an empty description or with the placeholder text as the description. That would be really helpful. Frankly I would suggest filing negative karma on the why do I have to... description you mentioned. I agree that it's simply not acceptable. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Fri, 28.06.13 01:17, Jan Kaluza (jkal...@redhat.com) wrote: Why would you want this? I mean, we rate-limit per-service anyway, so the issue of one app flooding evreything else should be mostly non-existant. And hence, what you are asking for is some policy control about what to delete first, which only really matters if your disk space is very very limited? Would you consider it sane to log say Apache traffic to the journal? If not, then there's still logrotate in the picture, and daemons need to do the whole SIGHUP dance. You can ignore the rest of this message in that case. I have httpd module for that, the problem is this bug: https://bugzilla.redhat.com/show_bug.cgi?id=963620. Once we fix this particular problem described in the bug, it will be possible to log structured httpd information into journal. Right now it's possible, but the performance is not good. I think right now (and in the short-term/mid-term future) journald is not ready yet to fully replace classic log files as we know them for example from httpd, but I hope in some long-term future, it will be done. There are clear benefits of journald logging I would like to have in httpd. This is pretty much in-line with how we see it from upstream journald: we want journald to scale well enough that it can just work HTTP logs too. Currently it doesn't (we spend too much time on collecting the meta-data from /proc), but Jan and others have been working on kernel patches to get this improved. So, yeah, we are very interested in providing a building block for others, and cover all major usecases, even if our particularly own one is just system logs. And on the topic of splitting up journal files: doing this makes sense for access control reasons, and really only for that. Splitting things up does not make sense for filtering (please use filtering while viewing the files instead, it's more powerful, much more live and should be as performant), and not really for enforcing data retention policies either (for that we should probably repack the journals while dropping unwanted stuff). Sometimes I've thought it'd be nice if it was easy to spin up a per-application journal daemon, with its own configuration and storage. Perhaps optionally an admin could use journalctl to see a merged view of these extended service journals with the system journal. Our clear approach is to have a unified database and filter at display time. (Note that the reason why we have the per-uid split up mode is actually a cloud setup, where UIDs map to customers, and each customer should get access to his own service logs). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Sat, 29.06.13 04:46, P J P (pj.pan...@yahoo.co.in) wrote: Hi, - Original Message - From: Lennart Poettering mzerq...@0pointer.de Subject: Re: logrotate(8) and copytruncate as default journald is the only writer, it doesn't need locking. The changes it does are done in a way so that concurrent readers will either see the changes or not, but never half-written changes. I see. How is that done? Does journald also renames the current file and creates a new one and continues writing to that new file?? It will create a new file and rename the old one. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On 2013-06-28 17:51, Chris Murphy wrote: On Jun 28, 2013, at 4:20 PM, Adam Williamson awill...@redhat.com wrote: I think you may be labouring under a bit of a misapprehension about what should be tested, here. The distinction between a TC and an RC is not large. An RC can only happen after freeze and must have all blockers fixed: if a build after freeze doesn't have all blockers addressed, we call it a TC. The distinction between TC and RC is large in that an RC1 *could* be final release. Yes, I did address that in the rest of the mail. I was making a general point, not a specific one. And since this particular bug wasn't in TC6 but was in the very next build, RC1, I think that's consistent with suggesting more time between an RC and a go/no-go. If we do this, we are going to have more slips. _Considerably_ more slips. That is the trade-off. I don't think it's one people will be happy with. It's really that simple. Although even better than that would be more recruitment of Mac users to do installation testing, so that it's possible to get installation tests done for at least RC1s. I tested it in a VM, foolishly not testing it on baremetal. RC2 hit, and I missed that since RC3 came soon after and immediately tested that on baremetal. But between RC3 and go/no-go was a matter of hours. Because RC3 was RC2 with a single very precise change; we were basically expecting to be GO on RC2 when I went to sleep on Wednesday night, then an issue was found just after I went to sleep, and we decided to go ahead and just fix it and respin. The change was isolated in the anaconda TUI interface's Software Selection spoke so really couldn't possibly affect anything else. We do actually have more than a few people with Macs: you, Fedora QA's Brno team, mjg59, and I think someone on anaconda team has one. It would be nice if at least one of the above could test each *C, though I realize bare metal testing is a PITA and I hate it myself. If we actually blocked on Mac dual boot by policy, we would have a test case for it, and we would not have considered releasing without having that test case run in at least one of the RCs, FWIW. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On Sex, 2013-06-28 at 14:16 -0700, Adam Williamson wrote: On Fri, 2013-06-28 at 22:43 +0200, drago01 wrote: On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 28 Jun 2013 22:13:09 +0200 drago01 drag...@gmail.com wrote: On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: and we have no history of producing updated install images. Is there *any* reason why we can't? This sounds like a reasonable thing to do. Just because we have not done it in the past is not a reason not to. Sure we could. We would need to: * Have some way to freeze things so we could stablize for the release. We should use the GA package set + the fixed build not get all updates in. It is to fix one bug not to create updated images. I think there's some confusion here. You now actually seem to be talking about the specific question of producing an updated install image one time, for this one issue, but at first it seemed like you were advocating it as The New Way Forward. Assuming we find a single simple change that Fixes Mac UEFI Dual Boot in anaconda, then from a purely technical standpoint, yes, we could theoretically throw together a boot ISO and DVD with the fix in quite easily. All it'd need would be a new build of anaconda with only that fix, and someone to run pungi a couple of times. Given the apparent constraints on network access on Macs it might even make sense to do that in this particular case, if someone wants to spend the time on it. The way I'd envisage that happening, though, is that we stick them up pretty unofficially with a 'this is an image we think might install better on Macs, use it if you like' label on it. I definitely wouldn't want to go around sounding trumpets and calling it Fedora 19.1. Something altogether less official and more low key seems appropriate. I like the idea of 19.1 pretty unofficially or untested, which fix some issues on mac installs. Which is basically someone run pungi with new boot installer stuff. Fedora installer already install updates, when we internet, if I'm not wrong or at least in my install methods, so we don't need a 19.1 for others things that aren't in boot process. And if some team fix and release some packages that fix boots of any kind why not ? Release 19.1 could be only directories releases/19.1/Fedora/$arch/iso and releases/19.1/Fedora/$arch/os/EFI,images and isolinux , without all packages . -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
On 29/06/2013, at 7:12, Chris Murphy li...@colorremedies.com wrote: On Jun 28, 2013, at 10:39 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Jun 28, 2013 at 10:25:58AM -0600, Kevin Fenzi wrote: - Say we ground all the wheels to a halt and slipped for this bug. Where to do we draw the line? If someone comes up with a bug at 9:50am on release morning, do we cancel everything? There has to be a point where we say sorry, it's too late and this has been it since it makes sense from a logistic standpoint. If at 9:50am on release morning we discovered that the installer would format all connected drives if the month had two digits, I'd like to think we'd do something about it. It's inevitably going to be a judgement call based on the perceived harm in releasing as is against the harm caused by slipping, just as it is at any other point in the release process. Current policy effectively says There is no issue sufficient to delay release after we've said an image is good, and I don't believe that that's true. One possible solution is either more padding (time) between any RC release and go/no-go; or if certain listed packages, like anaconda, pykickstart, blivet, etc. are touched in even a seemingly trivial way, then the full QA test matrix has to be retested. Maybe that's already implicitly the case, but I don't know if it's a rule. But what definitely isn't the case is, Macs are still not officially supported by QA for blocker status for Mac specific major bugs. If a Mac only bug comes up, block status is rejected on the basis that too few people will experience the bug. So before I'd suggest holding up Fedora 19, I think Macs need to have a promoted hardware status. Something not totally dissimilar happened for Fedora 18 that was also a problem for Macs. That's bug 893839 Mac EFI from DVD and LiveCD ISO burned to actual DVD media results in grub prompt, no boot. I didn't find that until final, definitely too late. But the final release series of RC's happen very quickly, and any allowed change is by definition significant (i.e. necessary) or it simply wouldn't happen, but that also makes the change higher risk than other changes. So I think more time padding is needed between an RC and go/nogo. Doesn't matter much : radeon macs get hit by https://bugzilla.redhat.com/show_bug.cgi?id=975280 on all kernel 3.9. (no x, no plymouth, black screen) So fedora 19 is somewhat useless on some intel macs. Sincerely, William -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: logrotate(8) and copytruncate as default
On Sat, Jun 29, 2013 at 02:42:11AM +0200, Lennart Poettering wrote: That's why we are so strong on filtering the dataset when you look at it. May I recommend watching this video? https://www.youtube.com/watch?v=i4CACB7paLc I was there at that talk. :) I think the journal is cool. It does great things. I like having everything together. But, giving restricted views into the data isn't a really crazy case. The use case I give may not be as important as it used to be, and it's certainly covered by having apache just right its own logs. *But*, there are other situations -- like requiring extra identity assurance for access to authpriv data -- which are much more important. If we ever want systemd journal to be the default general logging solution, we need that. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 status is ALIVE, GA on July 02, 2013
We do actually have more than a few people with Macs: you, Fedora QA's Brno team, mjg59, and I think someone on anaconda team has one. It would be nice if at least one of the above could test each *C, though I realize bare metal testing is a PITA and I hate it myself. I do bare metal testing on intel macs but more often than not i find bug reports around the kernel are just flatly ignored, so I've kind of given up. Just my 2c William-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 844988] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=844988 --- Comment #1 from lionel.c...@cern.ch --- The latest version of Test::Class on CPAN is now 0.39. This is the version to use everywhere. Please upgrade in Fedora as well as EPEL5 and EPEL6. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=lkFjjIHiTpa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 979143] rpm -q --provides perl has superfluous output
https://bugzilla.redhat.com/show_bug.cgi?id=979143 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Petr Pisar ppi...@redhat.com --- Thank you for the report. This is caused by unicore/Name.pm redefining charnames module for internal purposes. We shall skip this file when scanning for provides. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EbnrqPTy00a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Digest-SHA-5.85.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Digest-SHA: 7e9d19d00a66363012a6fdb3ae3ffd22 Digest-SHA-5.85.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Digest-SHA] 5.85 bump
commit 4b6c557a95836d21ac898dd851350bc950ddf523
Author: Petr Písař ppi...@redhat.com
Date: Fri Jun 28 10:48:08 2013 +0200
5.85 bump
.gitignore |1 +
perl-Digest-SHA.spec | 14 +-
sources |2 +-
3 files changed, 15 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1a8dc3e..67dd9fe 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@ Digest-SHA-5.45.tar.gz
/Digest-SHA-5.82.tar.gz
/Digest-SHA-5.83.tar.gz
/Digest-SHA-5.84.tar.gz
+/Digest-SHA-5.85.tar.gz
diff --git a/perl-Digest-SHA.spec b/perl-Digest-SHA.spec
index 83f7961..65c78f4 100644
--- a/perl-Digest-SHA.spec
+++ b/perl-Digest-SHA.spec
@@ -1,6 +1,6 @@
Name: perl-Digest-SHA
Epoch: 1
-Version:5.84
+Version:5.85
Release:1%{?dist}
Summary:Perl extension for SHA-1/224/256/384/512
License:GPL+ or Artistic
@@ -10,13 +10,22 @@ Source0:
http://www.cpan.org/authors/id/M/MS/MSHELOR/Digest-SHA-%{version
# Since 5.80, upstream overrides CFLAGS because they think it improves
# performance. Revert it.
Patch0: Digest-SHA-5.84-Reset-CFLAGS.patch
+BuildRequires: perl
+BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Getopt::Std)
+BuildRequires: perl(strict)
# Run-time
BuildRequires: perl(Carp)
BuildRequires: perl(DynaLoader)
BuildRequires: perl(Exporter)
+BuildRequires: perl(Fcntl)
+BuildRequires: perl(integer)
+BuildRequires: perl(vars)
# Optional run-time
BuildRequires: perl(Digest::base)
+# Tests
+BuildRequires: perl(FileHandle)
# Optional tests
%if !%{defined perl_bootstrap}
BuildRequires: perl(Test::Pod) = 1.00
@@ -63,6 +72,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Jun 28 2013 Petr Pisar ppi...@redhat.com - 1:5.85-1
+- 5.85 bump
+
* Mon Mar 11 2013 Petr Pisar ppi...@redhat.com - 1:5.84-1
- 5.84 bump
diff --git a/sources b/sources
index e1a3cfa..fa5a681 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5e8a952b2728bac2a44caefc0abc9642 Digest-SHA-5.84.tar.gz
+7e9d19d00a66363012a6fdb3ae3ffd22 Digest-SHA-5.85.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Digest-SHA/f19] 5.85 bump
Summary of changes: 4b6c557... 5.85 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Digest-SHA/f18] Deal with calling destructor multiple times
commit b186646a945e0d41dfccd035710c521b0961a71a
Author: Petr Písař ppi...@redhat.com
Date: Fri Jun 28 14:12:28 2013 +0200
Deal with calling destructor multiple times
Digest-SHA-5.84-repeated_shaclose.patch | 30 ++
perl-Digest-SHA.spec|8 +++-
2 files changed, 37 insertions(+), 1 deletions(-)
---
diff --git a/Digest-SHA-5.84-repeated_shaclose.patch
b/Digest-SHA-5.84-repeated_shaclose.patch
new file mode 100644
index 000..ce08e9d
--- /dev/null
+++ b/Digest-SHA-5.84-repeated_shaclose.patch
@@ -0,0 +1,30 @@
+Workaround for repeated calls to shaclose()
+
+CPAN RT#86295
+Ported from Digest-SHA-5.85.
+
+diff -Naru Digest-SHA-5.84/lib/Digest/SHA.pm Digest-SHA-5.85/lib/Digest/SHA.pm
+--- Digest-SHA-5.84/lib/Digest/SHA.pm 2013-03-10 01:36:10.0 +0100
Digest-SHA-5.85/lib/Digest/SHA.pm 2013-06-26 13:05:27.0 +0200
+@@ -62,7 +62,7 @@
+
+ sub DESTROY {
+ my $self = shift;
+- shaclose($$self) if $$self;
++ if ($$self) { shaclose($$self); $$self = undef }
+ }
+
+ sub clone {
+diff -Naru Digest-SHA-5.84/SHA.xs Digest-SHA-5.85/SHA.xs
+--- Digest-SHA-5.84/SHA.xs 2013-03-09 21:38:02.0 +0100
Digest-SHA-5.85/SHA.xs 2013-06-23 17:16:35.0 +0200
+@@ -31,6 +31,9 @@
+ int
+ shaclose(s)
+ SHA * s
++CODE:
++ RETVAL = shaclose(s);
++ sv_setiv(SvRV(ST(0)), 0);
+
+ int
+ shadump(file, s)
diff --git a/perl-Digest-SHA.spec b/perl-Digest-SHA.spec
index 6d9110e..dbba683 100644
--- a/perl-Digest-SHA.spec
+++ b/perl-Digest-SHA.spec
@@ -1,7 +1,7 @@
Name: perl-Digest-SHA
Epoch: 1
Version:5.74
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Perl extension for SHA-1/224/256/384/512
License:GPL+ or Artistic
Group: Development/Libraries
@@ -10,6 +10,8 @@ Source0:
http://www.cpan.org/authors/id/M/MS/MSHELOR/Digest-SHA-%{version
# Fix double-free when loading Digest::SHA object
# https://rt.cpan.org/Public/Bug/Display.html?id=82655
Patch0: Digest-SHA-5.81-Fix-RT82655.patch
+# Fix for multiple destructor call, CPAN RT#86295
+Patch1: Digest-SHA-5.84-repeated_shaclose.patch
BuildRequires: perl(ExtUtils::MakeMaker)
# Run-time
@@ -39,6 +41,7 @@ handle all types of input, including partial-byte data.
%prep
%setup -q -n Digest-SHA-%{version}
%patch0 -p1
+%patch1 -p1
chmod -x examples/*
perl -MExtUtils::MakeMaker -e 'ExtUtils::MM_Unix-fixin(q{examples/dups})'
@@ -64,6 +67,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Jun 28 2013 Petr Pisar ppi...@redhat.com - 1:5.74-4
+- Deal with calling destructor multiple times (CPAN RT#86295)
+
* Wed Jan 16 2013 Jitka Plesnikova jples...@redhat.com - 1:5.74-3
- Add patch to fix RT#82655.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
