Re: Systemd boot issue
Hi, After removing 'rhgb quiet' and adding 'systemd.log_level=debug systemd.log_target=console' it generates a huge pile of debug messages at halts at - Switching root. I tried booting the _same_ 3.16.0 kernel on another F20 machine, it stops at the same spot. :( --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Nonresponsive maintainer: Takanori Matsuura
On Tue, Sep 9, 2014 at 11:32 AM, Dmitrij S. Kryzhevich wrote: > Talking about autoconf-archive, may be move information about it's orphaning > in new separate thread? I've tracked the CNUCNU bug of it for a long time: https://bugzilla.redhat.com/show_bug.cgi?id=876494 I can take over this package if you don't want. Thanks. Yours sincerely, Christopher Meng http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dist-git for Copr
On 09/10/2014 03:51 AM, Colin Walters wrote: If we're shipping binaries, we also have to ship the source code. Just on general principle, and many licenses require it. Every build of package also include rebuilt src.rpm, which we also store in resulting yum repo. -- Miroslav Suchý Red Hat Satellite Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dist-git for Copr
On Mon, Sep 8, 2014, at 11:45 AM, Simo Sorce wrote: > Does it mean the only way to build in copr would be to commit in git ? > I build one-off for testing and although I do not put anything "fishy" > in copr, I am not it would have any value to waste permanent space in > git with most of the tests I do. If we're shipping binaries, we also have to ship the source code. Just on general principle, and many licenses require it. Best to get over the fear of pushing ugly code. (The waste of space is not the commits to dist git, it's the lookaside cache as presently implemented...) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned autoconf-archive
Hello, during implementation of the one of the "Unresponsive maintainer policy" one package did not get it's maintainer: autoconf-archive According to [1] there are some "awaiting review" statuses, but package still orphaned. If you need it, please, take care of it. Dmitrij. [1] https://admin.fedoraproject.org/pkgdb/package/autoconf-archive/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2014-09-10)
On Sep 9, 2014 8:27 PM, "Michael Cronenworth" wrote: > > On 09/09/2014 06:21 PM, Josh Boyer wrote: >> >>date -d '2014-09-09 17:00 UTC' > > > Typo? (including the subject date) Sigh. Yes. Sorry, it's tomorrow 2014-09-10. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2014-09-09)
On 09/09/2014 06:21 PM, Josh Boyer wrote: date -d '2014-09-09 17:00 UTC' Typo? (including the subject date) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2014-09-09)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-09-09 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1178 Fedora 21 scheduling strategy .fesco 1178 https://fedorahosted.org/fesco/ticket/1178 = New business = #topic #1338 Non-responsive maintainer: masahase .fesco 1338 https://fedorahosted.org/fesco/ticket/1338 #topic #1339 missing acl's for some packages for epel7 .fesco 1339 https://fedorahosted.org/fesco/ticket/13389 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Systemd boot issue
Hello Daniel, Chris, Thank you so much for sharing the links and the notes, much appreciate it. > On Wednesday, 10 September 2014 12:23 AM, Daniel J Walsh wrote: > > Did you try to boot with enforcing=0? > To see if it is an SELinux issue? Yes I tried with enforcing=0, it does not seem to help. It still halts at the same spot. Upon removing 'rhgb quiet' parameters from the boot line, it shows systemd-journla[12321]: received SIGTERM And the screen before that is assorted with messages like: /systemd-fstab-?[23213]: used greatest stack depth: 12332 ... ... systemd-udevd[14322]: used greatest stack depth: 12920 ... ...not sure what the real glitch is. I'll try more...let's see. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Systemd boot issue
Did you try to boot with enforcing=0? To see if it is an SELinux issue? On 09/09/2014 09:46 AM, P J P wrote: > Hello, > > I've been trying to boot into kernel-3.16.0 on a F19 machine. But it just > stops after saying > > .. > [OK] Reached target Initrd Default target > > System is not hung, but there is no activity/progress either. I did search > about it, some say it's because of SELinux. But other kernels do boot with > SELINUX=enforcing on my machine, so I'm not sure. I asked on IRC channels, > but no fix in sight yet. > > Is it a familiar issue to anyone? Is there a way to debug what Systemd is > doing after printing above message?? > > Thank you. > --- > Regards >-Prasad > http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-PPIx-Utilities] Fix FTBFS with Perl::Critic 1.122 (#1139503)
commit cbe255c79d5fce3dfce63e1f3324fccf46f85514
Author: Paul Howarth
Date: Tue Sep 9 17:44:24 2014 +0100
Fix FTBFS with Perl::Critic 1.122 (#1139503)
- Avoid copyright.t more forcefully, as it is now upsetting Perl::Critic too
- Use %license where possible
perl-PPIx-Utilities.spec | 24 +---
1 files changed, 21 insertions(+), 3 deletions(-)
---
diff --git a/perl-PPIx-Utilities.spec b/perl-PPIx-Utilities.spec
index d301c05..8445bc2 100644
--- a/perl-PPIx-Utilities.spec
+++ b/perl-PPIx-Utilities.spec
@@ -1,6 +1,6 @@
Name: perl-PPIx-Utilities
Version: 1.001000
-Release: 15%{?dist}
+Release: 16%{?dist}
Summary: Extensions to PPI
Group: Development/Libraries
License: GPL+ or Artistic
@@ -8,6 +8,7 @@ URL:http://search.cpan.org/dist/PPIx-Utilities/
Source0:
http://search.cpan.org/CPAN/authors/id/E/EL/ELLIOTJS/PPIx-Utilities-%{version}.tar.gz
BuildArch: noarch
# Build:
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
# Run-time:
BuildRequires: perl(base)
@@ -17,6 +18,8 @@ BuildRequires:perl(PPI) >= 1.208
BuildRequires: perl(PPI::Document::Fragment) >= 1.208
BuildRequires: perl(Readonly)
BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Tests:
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(PPI::Document) >= 1.208
@@ -28,6 +31,7 @@ BuildRequires:perl(Test::More)
# PPI needed by Perl::Critic, so don't run extra tests when bootstrapping
%if 0%{!?perl_bootstrap:1}
BuildRequires: aspell-en
+BuildRequires: perl(File::Find)
BuildRequires: perl(File::Slurp)
BuildRequires: perl(Perl::Critic::Policy::Miscellanea::RequireRcsKeywords)
BuildRequires: perl(Test::Perl::Critic)
@@ -49,6 +53,11 @@ PPI::Nodes is in PPIx::Utilities::Node.
%prep
%setup -q -n PPIx-Utilities-%{version}
+# Remove date-sensitive copyright.t, which also upsets Perl::Critic
+# (#1139503)
+rm xt/author/copyright.t
+sed -i -e '/copyright\.t/d' MANIFEST
+
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -61,11 +70,16 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} \;
%check
make test
%if 0%{!?perl_bootstrap:1}
-make test TEST_FILES="$(echo $(find xt/ -name '*.t' | grep -Fv copyright.t))"
+make test TEST_FILES="$(echo $(find xt/ -name '*.t'))"
%endif
%files
-%doc Changes LICENSE README
+%if 0%{?_licensedir:1}
+%license LICENSE
+%else
+%doc LICENSE
+%endif
+%doc Changes README
%{perl_vendorlib}/PPIx/
%{_mandir}/man3/PPIx::Utilities.3pm*
%{_mandir}/man3/PPIx::Utilities::Exception::Bug.3pm*
@@ -73,6 +87,10 @@ make test TEST_FILES="$(echo $(find xt/ -name '*.t' | grep
-Fv copyright.t))"
%{_mandir}/man3/PPIx::Utilities::Statement.3pm*
%changelog
+* Tue Sep 9 2014 Paul Howarth - 1.001000-16
+- Avoid copyright.t more forcefully, as it is now upsetting Perl::Critic too
+- Use %%license where possible
+
* Sun Sep 07 2014 Jitka Plesnikova - 1.001000-15
- Perl 5.20 re-rebuild of bootstrapped packages
--
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: Systemd boot issue
On Sep 9, 2014, at 7:46 AM, P J P wrote: > Is there a way to debug what Systemd is doing after printing above message?? http://fedoraproject.org/wiki/How_to_debug_Dracut_problems http://freedesktop.org/wiki/Software/systemd/Debugging/ In such a case I always use rd.break to hopefully get a dracut prompt if the initramfs is failing. If that doesn't work and you still get a hang, then you'll need to read about rd.break= and setting it for a point prior to the failure to isolate. rd.debug will include a huge pile of everything the initramfs is doing, you might avoid this until you know whether it's the initramfs or systemd unit or service giving a problem. systemd.log_level=debug will produce quite a bit of systemd debug text. When I'm impatient I used both debug options at the same time, but it makes boot much slower. If you manage to get to a shell, journalctl -b -l is helpful since it's available in very early boot. Another possibility is if you can boot single user (emergency.target) successfully and enable the systemd early debug shell. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
Quoting Christopher (2014-09-08 21:35:23) > It'd be great if the fedpkg tool could do some of this. For example, fedpkg > could create git repos locally, from a template and a few questions, for > new packages, which could be pushed somewhere for review (usually GitHub, > I'd imagine). It could even create the review bug automatically, as well as > assist in the review process for the reviewer (setting the correct flags). > > Once approved and the package is created in pkgdb, git could be adjusted > automatically from a clone of this original repo created by the fedpkg tool. > > This puts some burden on the reviewer to review not only the package, but > also the use of the packaging process: ensure that the user created the git > repo correctly. But, that might not be a bad thing. I was struck by how > "manual" the new package process was, and how "automated" everything is > later. It's a big gap that could be closed with more tools on the "prepare > for review" side of things. I think this is excellent idea. (Mocked something already in response to Pierre) On the other hand, I think that webui process should be kept (just for sake of people who don't prefer CLI tools). Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Mon, 2014-09-08 at 08:43 +0100, Richard W.M. Jones wrote: > > > Anyway, systemd now does the following which it didn't do in F15: > > > > > > - has its own network configuration system > > > > ...which we don't use. > > So why is the tool there? Well, because it's part of upstream systemd? We ship *lots* of code we don't use by default, this is hardly unusual. > > > - has a way to control firmware boot settings > > > - intercepts coredumps > > > > not on Fedora, abrt does that. > > It does on my F22 machine: > > $ cat /proc/sys/kernel/core_pattern > |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e > > I haven't done anything in particular that enables this, but it's > possibly because abrt is not installed on this headless system. Yeah, I should say 'not in our default configuration'. I noticed yesterday it picked up a crash in python during anaconda boot. I don't actually know what the point of this mechanism is, but hey, I still got the coredump file out, so...no problem? I dunno. > > > - has the journal > > > > was *extensively* discussed and argued about when it landed and whenever > > changes were made to its behaviour (see list archives). > > > > > - has tools for setting the system time and timezone, and locale > > > > Sure. They're useful. > > They also don't work unless a daemon is running, meaning you can't > run them in a chrooted filesystem. Then use a different mechanism, the way these tools actually work and the config files they're backed by are documented. > > > - has a firstboot mechanism > > > > Where? In any case, Fedora doesn't use it. > > systemd-firstboot(1) on F22. Hum, I don't see it on F21. I dunno, can't say anything about it. > > > - detects virtualization (long story here, but a very bad idea to > > >encourage programs to do this) > > > > I don't believe any Fedora units use this ability. It's there for people > > who want to use it. > > At least open-vm-tools uses it (it shouldn't). > > > > - has a program for comparing /etc configurations > > > - has its own version of the FHS and a tool for managing it > > > > Erm. What? > > systemd-delta(1) OK, so it's a tool that does something useful. What's your issue with it? > file-hierarchy(7) Oh, yeah. That's kind of documentation-after-the-fact, as I see it. FHS has moved painfully slowly lately, and there are cases where systemd just had to go ahead and *do* something that isn't covered by FHS, so it picked an approach. the man page documents those cases and the approach systemd took. Distributions already extend far beyond FHS (and sometimes disregard it) in quite a lot of other ways, so I'm not sure this is a problem. I worry more about cases where systemd actively conflicts with things that are explicitly specified in FHS, but even that isn't always *necessarily* wrong. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1136723] perl-Workflow-1.41-2.fc22 FTBFS randomly: 'One observation sent on workflow fetch to two observers' t/workflow.t test fails
https://bugzilla.redhat.com/show_bug.cgi?id=1136723 Petr Pisar changed: What|Removed |Added External Bug ID||CPAN 87698 -- 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=ElzOLb7rq6&a=cc_unsubscribe -- 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
File Test-Simple-1.001006.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Simple: 581ac4d2d7ace1f56409bc112e8ad02c Test-Simple-1.001006.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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Tue, 2014-09-09 at 15:28 +0200, Reindl Harald wrote: > Am 09.09.2014 um 08:26 schrieb Adam Williamson: > > certificate_list > > This is a sequence (chain) of certificates. The sender's > > certificate MUST come first in the list. Each following > > certificate MUST directly certify the one preceding it. Because > > certificate validation requires that root keys be distributed > > independently, the self-signed certificate that specifies the root > > certificate authority MAY be omitted from the chain, under the > > assumption that the remote end must already possess it in order to > > validate it in any case > > sure? Well, I mean, that's what's written down in the RFC, you can go read it for yourself. I'm not setting myself up as the world's leading authority on TLS, I need at least another fifteen minutes of googling before I do that. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20140909 changes
Compose started at Tue Sep 9 07:15:02 UTC 2014 Broken deps for armhfp -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [PyKDE] PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) >= 0:10.0 [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [couchdb] couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [docker-registry] docker-registry-0.7.3-1.fc21.noarch requires docker-io [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [ejabberd] ejabberd-2.1.13-8.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [elpa] elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1 [erlang-basho_metrics] erlang-basho_metrics-1.0.0-10.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-bitcask] erlang-bitcask-1.6.3-1.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-cl] erlang-cl-1.2.1-2.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-ebloom] erlang-ebloom-1.1.2-4.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-eleveldb] erlang-eleveldb-1.3.2-2.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-emmap] erlang-emmap-0-0.8.git05ae1bb.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-erlsyslog] erlang-erlsyslog-0.6.2-6.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esasl] erlang-esasl-0.1-15.20120116git665cc80.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esdl] erlang-esdl-1.3.1-3.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-js] erlang-js-1.2.2-5.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-sd_notify] erlang-sd_notify-0.1-1.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-skerl] erlang-skerl-1.1.0-7.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-snappy] erlang-snappy-1.0.3-0.7.git80db168.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [ghc-hint] ghc-hint-devel-0.4.2.0-2.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [hibernate-search] hibe
Re: Systemd boot issue
On Tue, 9 Sep 2014, P J P wrote: I've been trying to boot into kernel-3.16.0 on a F19 machine. But it just stops after saying Is it a familiar issue to anyone? Is there a way to debug what Systemd is doing after printing above message?? I had similar issues, and I'm still on 3.14.7-100 on my f19 machine. I even had to switch to the kernel-debug package because the non-debug version wouldn't boot either, similarly to what you describe. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Systemd boot issue
Hello, I've been trying to boot into kernel-3.16.0 on a F19 machine. But it just stops after saying ... [OK] Reached target Initrd Default target System is not hung, but there is no activity/progress either. I did search about it, some say it's because of SELinux. But other kernels do boot with SELINUX=enforcing on my machine, so I'm not sure. I asked on IRC channels, but no fix in sight yet. Is it a familiar issue to anyone? Is there a way to debug what Systemd is doing after printing above message?? Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: timedated is broken by default in F21
On Tue, 2014-09-09 at 08:37 -0500, Michael Catanzaro wrote: > (1) carry a downstream patch to > systemd, (2) carry a downstream patch to gnome-control-center Note that (1) would be much easier, since that patch is small and already exists. I expect other distros will either do this, or, more likely, leave gnome-control-center broken. I can see Fedora switching to timesyncd, but I doubt there's a realistic chance of that happening in Debianland or other major distros. > or (3) > drop chrony from the default install. (Is there any reason to keep > chrony?) Reading [1], it looks like there is a good reason to keep using chrony. [1] http://lists.freedesktop.org/archives/systemd-devel/2014-August/022537.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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
timedated is broken by default in F21
On Tue, 2014-09-09 at 10:38 +0200, Miroslav Lichvar wrote: > Yeah, that was nice, when it worked as we wanted. Unfortunately, with > the latest systemd the NTP service which is enabled/disabled by > timedated is no longer selected from the services installed on the > systemd, but is now hardcoded to the systemd SNTP client (timesyncd). > > That means the NTP status reported in GNOME settings may be incorrect, > enabling/disabling NTP will do nothing if another NTP service is > enabled > or timesyncd will be enabled even when our default NTP client > (chronyd) is installed. > > https://bugzilla.redhat.com/show_bug.cgi?id=1136905 > > Upstream is not interesting in having this configurable. Should we be > patching timedated? Or GNOME? Miroslav, This is clearly a problem. We don't want the NTP switch in gnome-control-center to stop working just because a distro decided to use an "alternative" NTP client like ntpd or chronyd. It looks like we have three options: (1) carry a downstream patch to systemd, (2) carry a downstream patch to gnome-control-center, or (3) drop chrony from the default install. (Is there any reason to keep chrony?) If all three sets of maintainers are resistant to such a change, then we should escalate to FESCO and let them choose for us. Michael signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
Am 09.09.2014 um 08:26 schrieb Adam Williamson: > certificate_list > This is a sequence (chain) of certificates. The sender's > certificate MUST come first in the list. Each following > certificate MUST directly certify the one preceding it. Because > certificate validation requires that root keys be distributed > independently, the self-signed certificate that specifies the root > certificate authority MAY be omitted from the chain, under the > assumption that the remote end must already possess it in order to > validate it in any case sure? IMHO normally i bild a PEM file for httpd over years with cat intermediate.pem ca.pem cert.pem key.pem > your.pem https://www.ssllabs.com/ssltest/ also says that's fine https://www.ssllabs.com/ssltest/analyze.html?d=secure.thelounge.net well, i happily admit that i did it wrong and rebuild the PEM-files while the order has some logic for me * "ca.pem" is sigend by "intermediate.pem" * first load "intermediate.pem" to verify "ca.pem" against it * at the end the server cert signed by the chain before signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unresponsive maintainer: masahase
On 09/02/2014 10:03 AM, Michael Cronenworth wrote: It has been two weeks without any word from the maintainer or anyone that knows him. I'm now requesting maintainership of linux-igd. I have created a FESCo ticket to get this addressed. https://fedorahosted.org/fesco/ticket/1338 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote: > certificate_list > This is a sequence (chain) of certificates. The sender's > certificate MUST come first in the list. Each following > certificate MUST directly certify the one preceding it. We recently learned the hard way in GNOME that if you rely on this behavior, some sites won't work because webmasters test their sites with NSS, and NSS doesn't care which order certificates are sent in. (gnutls can reorder certificates too, though.) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dist-git for Copr
Le 09/09/2014 09:02, Miroslav Suchý a écrit : > On 09/08/2014 05:45 PM, Simo Sorce wrote: >> Does it mean the only way to build in copr would be to commit in git ? > I'm not sure yet. But I would like to preserve it as option. I also hope we can keep the option to build from a source RPM URL. I build lot of packages this way (spec on github, srpm on my server) Having to move "all" my work to fedora (or Copr) dist-git will definitively be a blocker for me. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
Quoting Pierre-Yves Chibon (2014-09-08 11:55:06)
> On Mon, Sep 08, 2014 at 11:31:58AM +0200, Tomas Tomecek wrote:
> > Quoting Pierre-Yves Chibon (2014-09-05 17:08:39)
> > > New procedure
> > > =
> > >
> > > * packager opens a review-request on bugzilla
> > > * reviewer sets the fedora-review flag to ?
> > > * reviewer does the review
> > > * reviewer sets the fedora-review flag to +
> > > * packager goes to pkgdb2 to request new package and specifies:
> > >- package name
> > >- package summary
> >
> > How about taking this from specfile? (and therefore provide a tool for
> > maintaining specfiles & srpms for reviews)
>
> That would imply parsing the bugzilla ticket to find the spec file and then
> parse it again which itself implies knowing the bugzilla ticket number.
My point was mainly that if you are working on improving the process, there
should be automated as much stuff as possible.
I've read a topic by Mirek Suchy on fedora-devel today about hooking dist-git
with
copr and I think that review process could benefit out of it. Roughly, something
like this:
$ fedpkg new-package create-repo
Creating new dist-git repo with sample specfile.
$ ${EDITOR} *.spec
$ fedpkg copr new
Sets owner, project name, arches... and links the repo with copr project
together
$ fedpkg copr build --with-fedora-review
$ fedpkg new-package create-bugzilla
$ fedpkg new-package add-to-pkgdb
This is roughly from top of my head, but I think you'll get my point.
The new-package process would be so much easier (at least to me).
> I think it's just as easy to ask the user to do it.
>
> Note that we have an API endpoint to edit a package's information:
> https://admin.fedoraproject.org/pkgdb/api/#edit_a_package
> and a script to do it in pkgdb2:
> https://git.fedorahosted.org/cgit/pkgdb2.git/tree/utility/update_package_info.py
> (Although we still need to deploy this one in a cron job)
>
> Pierre
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Cheers,
Tomas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Tue, Sep 09, 2014 at 01:01:09PM +0100, Peter Robinson wrote: > >> >> on http://comments.gmane.org/gmane.linux.redhat.fedora.devel/199113 > >> >> *you* complain about systemd-readahead - guess what - if a virtual > >> >> machine is detected it is skipped > >> > > >> > And why is it a good idea to skip it on a virtual machine? > >> > >> guess what happens if you fire up 20 guests at the same > >> time prefetch a lot of data from a shared storage - if > >> the data is not cached at the host you overload disks > > > > How is that different from if you have a room full of physical > > machines using a single SAN? > > It would depend on how many of those are boot from SAN or local > storage for boot, in the case of boot from SAN they tend to also have > dedicated LUNs where as in most cases VMs are on the same LUN. It can > have similar issues but from experience there tends to be situations > that mitigate the issue with physical machines. Sure, we can mitigate the problem in both cases. I run all my VMs on separate iSCSI LUNs these days after seeing performance problems with sharing single LUNs. My point is that "network of physical machines" and "virtual machines on a physical host" are not really that different. They're not even that different when you look at them architecturally -- modern PCs have CPUs that communicate internally and with peripherals using networks; they have separate banks of memory arranged in NUMA nodes. It's common to locate storage and compute in separate places, with layers of caching in between. The difference, if any, is really just one of distances and outward appearance. Therefore I am suspicious of any Fedora package that ships with ConditionVirtualization in its unit file. It's likely covering over a bug in the package. What it should be doing is detecting the specific features it needs and using them, or exiting if they are not available. "It doesn't work virtualized" probably means it doesn't work on physical machines either, in some scenario or other. It maybe, might possibly be added by an operator after they've carefully analyzed some performance problem. At the same time, this issue is not some huge big deal we all need to worry about. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Old virt-v2v may be half-retired
On Sat, Sep 06, 2014 at 08:06:03PM +0100, Richard W.M. Jones wrote: > I tried to retire the old virt-v2v package: > > https://admin.fedoraproject.org/pkgdb/package/virt-v2v > > However I likely only "half-retired" it because although I'm a package > administrator, I'm not the owner, or something like that. In any case > I'm coordinating with the package owner and we will have it retired > properly by next week. > > The background here is that virt-v2v and virt-p2v have been rewritten > upstream over the past 6 months. The new version is integrated into > the libguestfs project. In Fedora virt-v2v will be built as a > subpackage of libguestfs >= 1.27.39. > > All of the above applies to Fedora >= 21 only, not to any earlier > versions, nor to EPEL. This should be fixed now. Please let me or Matt Booth (previous package owner) know if there are any problems. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
Am 09.09.2014 um 13:51 schrieb Richard W.M. Jones: > On Tue, Sep 09, 2014 at 12:37:45PM +0200, Reindl Harald wrote: >> >> Am 09.09.2014 um 12:33 schrieb Paolo Bonzini: >>> Il 07/09/2014 20:04, Reindl Harald ha scritto: on http://comments.gmane.org/gmane.linux.redhat.fedora.devel/199113 *you* complain about systemd-readahead - guess what - if a virtual machine is detected it is skipped >>> >>> And why is it a good idea to skip it on a virtual machine? >> >> guess what happens if you fire up 20 guests at the same >> time prefetch a lot of data from a shared storage - if >> the data is not cached at the host you overload disks > > How is that different from if you have a room full of physical > machines using a single SAN? then disable it there - so what you can't seriously blame a opportunity which is choosen as default for easy detectable cases because it does not magically recognize anything one could imagine how does that discussion lead to anything useful? * you don't like systemd-readahead? fine disable it * you don't like ConditionVirtualization? fine disable it and even if such conditions are not used in any single unit shipped with Fedora - there are a ton of options not used in shipped units - that don't change the fact i am *widely* use them while they all don't hurt you but they are there to give admins knowing the environemt a lot of useful *opportunities* you never had before without writing large and error prone initscripts cat /usr/lib/systemd/system/httpd.service | grep Directories | wc -l 85 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
>> >> on http://comments.gmane.org/gmane.linux.redhat.fedora.devel/199113 >> >> *you* complain about systemd-readahead - guess what - if a virtual >> >> machine is detected it is skipped >> > >> > And why is it a good idea to skip it on a virtual machine? >> >> guess what happens if you fire up 20 guests at the same >> time prefetch a lot of data from a shared storage - if >> the data is not cached at the host you overload disks > > How is that different from if you have a room full of physical > machines using a single SAN? It would depend on how many of those are boot from SAN or local storage for boot, in the case of boot from SAN they tend to also have dedicated LUNs where as in most cases VMs are on the same LUN. It can have similar issues but from experience there tends to be situations that mitigate the issue with physical machines. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20140909 changes
Broken deps for i386 -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [aws] aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel [blender] 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 [compat-gcc-34] compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ < 0:4.9.0 [cp2k] cp2k-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc22.i686 requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.i686 requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.i686 requires libtk8.5.so csound-tk-5.19.01-1.fc20.i686 requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [elk] elk-openmpi-2.3.22-7.fc21.i686 requires libmpi_usempi.so.1 [elpa] elpa-openmpi-2013.11-4.008.fc21.i686 requires libmpi_usempi.so.1 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.i686 requires libftdi.so.1 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [ga] ga-openmpi-5.3b-9.fc21.i686 requires libmpi_usempi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.i686 requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [lcg-util] lcg-util-1.16.0-3.fc21.i686 requires libgfal.so.1 lcg-util-libs-1.16.0-3.fc21.i686 requires libgfal.so.1 lcg-util-python-1.16.0-3.fc21.i686 requires libgfal.so.1 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [llvm] llvm-ocaml-3.4-15.fc22.i686 requires ocaml(Pervasives) = 0:4329e57fde14cc94b02a739d2595516b [ltsp] ltsp-client-5.4.5-8.fc21.i686 requires fuse-unionfs ltsp-server-5.4.
Re: New Group Calls For Boycotting Systemd
On Tue, Sep 09, 2014 at 12:37:45PM +0200, Reindl Harald wrote: > > Am 09.09.2014 um 12:33 schrieb Paolo Bonzini: > > Il 07/09/2014 20:04, Reindl Harald ha scritto: > >> on http://comments.gmane.org/gmane.linux.redhat.fedora.devel/199113 > >> *you* complain about systemd-readahead - guess what - if a virtual > >> machine is detected it is skipped > > > > And why is it a good idea to skip it on a virtual machine? > > guess what happens if you fire up 20 guests at the same > time prefetch a lot of data from a shared storage - if > the data is not cached at the host you overload disks How is that different from if you have a room full of physical machines using a single SAN? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
Am 09.09.2014 um 12:33 schrieb Paolo Bonzini: > Il 07/09/2014 20:04, Reindl Harald ha scritto: >> on http://comments.gmane.org/gmane.linux.redhat.fedora.devel/199113 >> *you* complain about systemd-readahead - guess what - if a virtual >> machine is detected it is skipped > > And why is it a good idea to skip it on a virtual machine? guess what happens if you fire up 20 guests at the same time prefetch a lot of data from a shared storage - if the data is not cached at the host you overload disks on the other hand long running virtualization hosts with plenty memory and shared memory pages you get the whole benefit anyways without support from the guest signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
Il 07/09/2014 20:04, Reindl Harald ha scritto: > on http://comments.gmane.org/gmane.linux.redhat.fedora.devel/199113 > *you* complain about systemd-readahead - guess what - if a virtual > machine is detected it is skipped And why is it a good idea to skip it on a virtual machine? Paolo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up for rawhide: rebase of texi2html fro 1.82 to 5.0
Hi everyone. Just a quick heads up that i've just quickly rebased texi2html to the current version. It's been a long standing request and i finally got around to do it quickly. As the jump is quite high i'm not sure if everything works out fine, so let me know if you're using texi2html and something breaks. Thanks! Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
> and others integration like crontab should be modular Systemd as cron is something that is built in. If you want a replacement, just install it and don't use this. It's a relatively small feature and it consumes just few kilobytes on your drive. It makes a lot of sense to have this burnt in because you can take control of your jobs from milisecond one. Things like run this two minutes after boot, or when my system is idle, or when an unit is (de)activated. Things like that. Plus in the containers you save one extra process. There is always a threshold between monolithic and modular design. Systemd is not only monolithic, it is modular as well. Some features is in core, some are modules (separate binaries with DBUS API). I think developers found the right threshold for most of the features. Even for chron-like feature there are good reasons. Even if you don't like chron-like features in core, send a patch with compilation option to turn if off. Not sure if maintainers will like it. I'd rather see this feature everywhere but this is solely my opinion. -- Later, Lukas #lzap Zapletal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Tue, 2014-09-09 at 10:34 +0200, Nikos Mavrogiannopoulos wrote: > On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote: > > On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote: > > > On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote: > > > > Unfortunately only NSS works. Both openssl and gnutls fail to connect to > > > > popular sites because of that change. It should not be assumed that the > > > > users of ca-certificates are only programs using nss. > > > > > > [1] is an interesting read. I get the impression that certificates are > > > being removed as long as there is a compatible replacement that NSS can > > > validate, based on NSS's custom strategies for certificate validation. > > > Is this claim accurate? > > > > "Custom strategies" is an interesting concept. AFAICS, the TLS standard: > > > > http://tools.ietf.org/html/rfc5246 > > > > does not exactly define 'standard' certificate verification strategies, > > so in a sense, they're *all* "custom". In other words, we're in good old > > Standard Ambiguity Land here. What that doc has to say about chains, > > AFAICS, is: > > You are referring to wrong document. Certificate validation is outside > the scope of TLS, and as you already notice it only mentions the format > of the chain and nothing more. A Certificate Path validation algorithm > is defined in RFC5280 by the PKIX working group which is (or was) the > relevant group for X.509 certificates in IETF. Ah, indeed, missed that one. Thanks. > So it may be that everyone uses a slightly different verification > algorithm, but we should expect at least the base-line to work. We > should not require software to be NSS. I think you're making a good point, but possibly too strongly...the ca-certificates folks are just trying to keep the database strong, it's not as if they set out to 'require software to be NSS'. As I mentioned, the folks maintaining the ca-certificates package are the same folks behind the Shared System Certificates feature - https://fedoraproject.org/wiki/Features/SharedSystemCertificates - which required a whole chunk of work to get the major TLS engines using the same certificate store; they're certainly not unfamiliar with openssl and gnutls, I don't think. The database uses NSS's certificate list as its starting point because it's the strongest contender for such a role, I think. Your report has already been taken up for action, it appears: https://bugzilla.mozilla.org/show_bug.cgi?id=986005 specifically: "I think Symantec should reach out to Amazon, and potentially to other customers, too, and suggest to remove intermediates from their server configurations that point to these old roots." "Brian, thanks for the pointer. I will work with our team to see about getting our cert chains updated for S3. Leaving in needinfo until I have more data." (from an Amazon employee) so...it seems like wheels are in motion. Note that the updates for both F19 and F20 are still in u-t and have not been pushed stable yet...as Kai explicitly sent the update to u-t with a high auto-push threshold and sent this email out to ask people to report cases where it caused problems, I'd say things are working out more or less as intended, you've raised an issue and it's being dealt with. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
- Original Message - > On Mon, Sep 08, 2014 at 08:36:21AM -0500, Michael Catanzaro wrote: > > On Sun, 2014-09-07 at 22:18 -0700, Adam Williamson wrote: > > > > - has tools for setting the system time and timezone, and locale > > > > > > Sure. They're useful. > > > > In GNOME, our settings panels previously only worked on Fedora and > > Debian, with some half-functional code for Arch and openSUSE, because > > each distro handled these differently and required custom code. Now we > > have no special casing for different distros, and it works everywhere > > these D-Bus interfaces are present (including systems without systemd > > that provide it, like Ubuntu). > > Yeah, that was nice, when it worked as we wanted. Unfortunately, with > the latest systemd the NTP service which is enabled/disabled by > timedated is no longer selected from the services installed on the > systemd, but is now hardcoded to the systemd SNTP client (timesyncd). > > That means the NTP status reported in GNOME settings may be incorrect, > enabling/disabling NTP will do nothing if another NTP service is enabled > or timesyncd will be enabled even when our default NTP client > (chronyd) is installed. > > https://bugzilla.redhat.com/show_bug.cgi?id=1136905 > > Upstream is not interesting in having this configurable. Should we be > patching timedated? Or GNOME? FYI, I have no interest in taking a patch to *re-add* special casing for that in GNOME. > > I don't really care where these interfaces live, but they need to exist > > somewhere, and systemd seems like the logical place for them. > > Agreed, the problem is systemd upstream may have a different view on > what exactly the interfaces should do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-readahead
Am 09.09.2014 um 10:29 schrieb Karel Zak: > On Sun, Sep 07, 2014 at 09:12:57AM +0200, drago01 wrote: >> On Sat, Sep 6, 2014 at 11:18 PM, Richard W.M. Jones >> wrote: >>> >>> Whenever my laptop boots, the hard disk is pegged at 100% and the >>> machine is unusable for another 2 minutes because of >>> "systemd-readahead", a misguided attempt to optimize the boot process. >>> Did we agree to this when we adopted systemd as an init replacement? >>> I don't remember init including all this other stuff. >> >> We had a readahead implementation before. > > Yep, I was maintainer and co-author of this package > >> On ssds it does not seem to >> help (nor hurt) much. On rotating media it used to help in the past >> but have not seen any recent numbers. > > after many optimizations and complete rewrite ..etc, I was not able to > see any really significant improvement. So.. my suggestion war to drop > the package from Fedora many years ago :-) > > IMHO it's better to optimize boot process and efficiently start only > really required services that load on boot all the unnecessary junk > and try to optimize the mess by readahead systemd-readahead combined with preload leads here on a fast RAID10 system that while the machine boots up and i go to my morning coffee / cigarette that after coming back and login my permanent used libraries and apps are already loaded in memory and on a machine with 16 GB RAM even Eclipse starts within 2 seconds on rotating media you can look at the file "/.readahead" what things are preloaded at boot signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Mon, Sep 08, 2014 at 08:36:21AM -0500, Michael Catanzaro wrote: > On Sun, 2014-09-07 at 22:18 -0700, Adam Williamson wrote: > > > - has tools for setting the system time and timezone, and locale > > > > Sure. They're useful. > > In GNOME, our settings panels previously only worked on Fedora and > Debian, with some half-functional code for Arch and openSUSE, because > each distro handled these differently and required custom code. Now we > have no special casing for different distros, and it works everywhere > these D-Bus interfaces are present (including systems without systemd > that provide it, like Ubuntu). Yeah, that was nice, when it worked as we wanted. Unfortunately, with the latest systemd the NTP service which is enabled/disabled by timedated is no longer selected from the services installed on the systemd, but is now hardcoded to the systemd SNTP client (timesyncd). That means the NTP status reported in GNOME settings may be incorrect, enabling/disabling NTP will do nothing if another NTP service is enabled or timesyncd will be enabled even when our default NTP client (chronyd) is installed. https://bugzilla.redhat.com/show_bug.cgi?id=1136905 Upstream is not interesting in having this configurable. Should we be patching timedated? Or GNOME? > I don't really care where these interfaces live, but they need to exist > somewhere, and systemd seems like the logical place for them. Agreed, the problem is systemd upstream may have a different view on what exactly the interfaces should do. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote: > On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote: > > On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote: > > > Unfortunately only NSS works. Both openssl and gnutls fail to connect to > > > popular sites because of that change. It should not be assumed that the > > > users of ca-certificates are only programs using nss. > > > > [1] is an interesting read. I get the impression that certificates are > > being removed as long as there is a compatible replacement that NSS can > > validate, based on NSS's custom strategies for certificate validation. > > Is this claim accurate? > > "Custom strategies" is an interesting concept. AFAICS, the TLS standard: > > http://tools.ietf.org/html/rfc5246 > > does not exactly define 'standard' certificate verification strategies, > so in a sense, they're *all* "custom". In other words, we're in good old > Standard Ambiguity Land here. What that doc has to say about chains, > AFAICS, is: You are referring to wrong document. Certificate validation is outside the scope of TLS, and as you already notice it only mentions the format of the chain and nothing more. A Certificate Path validation algorithm is defined in RFC5280 by the PKIX working group which is (or was) the relevant group for X.509 certificates in IETF. That is the only path validation algorithm described in a standard, and although no-one is required to support that, it pretty much defines the base-line. Our ca-certificates (in testing) would fail to connect to amazon.com if the RFC5280 validation is used, as it removed a root which is still active and used by popular domains. So it may be that everyone uses a slightly different verification algorithm, but we should expect at least the base-line to work. We should not require software to be NSS. regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-readahead
On Sun, Sep 07, 2014 at 09:12:57AM +0200, drago01 wrote: > On Sat, Sep 6, 2014 at 11:18 PM, Richard W.M. Jones wrote: > > > > Whenever my laptop boots, the hard disk is pegged at 100% and the > > machine is unusable for another 2 minutes because of > > "systemd-readahead", a misguided attempt to optimize the boot process. > > Did we agree to this when we adopted systemd as an init replacement? > > I don't remember init including all this other stuff. > > We had a readahead implementation before. Yep, I was maintainer and co-author of this package > On ssds it does not seem to > help (nor hurt) much. On rotating media it used to help in the past > but have not seen any recent numbers. after many optimizations and complete rewrite ..etc, I was not able to see any really significant improvement. So.. my suggestion war to drop the package from Fedora many years ago :-) IMHO it's better to optimize boot process and efficiently start only really required services that load on boot all the unnecessary junk and try to optimize the mess by readahead. Karel -- Karel Zak http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dist-git for Copr
On 09/08/2014 05:45 PM, Simo Sorce wrote: Does it mean the only way to build in copr would be to commit in git ? I build one-off for testing and although I do not put anything "fishy" in copr, I am not it would have any value to waste permanent space in git with most of the tests I do. I'm not sure yet. But I would like to preserve it as option. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
