Re: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break
On Do, 2014-12-18 at 10:43 -0500, Bastien Nocera wrote: > > - Original Message - > > Hi, > > > > > > On the other hand, if you install something and it starts listening and > > > > you didn’t know that, > > > > > > If you install something from Fedora and it does that, then it's a bug in > > > the > > > application. > > > > No. It's you solving your problem with gnome-user-share and declaring > > the fallout somebody elses problem so you can safely ignore it. > > It's in the packaging guidelines that server applications shouldn't > auto-start. > It's not like I'm making this up... (a) Bugs happen. (b) There are third party repos. (c) I might want use+enable the server apps and still have them reachable in trusted networks only. > > I want the guests vnc > > display be reachable in my home networks and not reachable in > > public networks. Doing it with the firewall works. > > You found a use for the firewall that's still running. Yea, right. And exactly that's why I think firewall setup should be alot simpler than it is now. Less zones, better names for them, ability to set them per network without digging deep into the network config tool. Problem is gnome takes the opposite direction: Hide the firewall. > > (2) Heck, even the gnome-user-share UI shows that. Pick "Remote > > Login", notice that you can NOT select networks for sharing. > > This isn't gnome-user-share. It's the sharing panel in the control-center. > And it's > not there because I wasn't sure whether changing the status quo for this was > 1) necessary 2) how to implement it without breaking the setup for > administrators if > the user can choose to enable/disable the SSH server themselves. I'd suggest to simply use the firewall. Do you seriously consider to automatically start/stop ssh as the machine switches networks? What if the machine has two active network interfaces with different trust levels. > I don't see how keeping the status quo for one (system-wide) service > necessarily > invalidates the design decisions done for all the other (user-wide) services. I've picked just one example. There are alot more system wide services which are facing the very same problem. mdns & cups are typical for desktops. Developer workstations might run a git server, also all sorts of server services (http, sql, gluster, ...) for testing purposes. The qemu example goes into that category too. > > Yes, I know why you can't pick networks for ssh. But this IMO clearly > > shows that the "just don't listen on untrusted networks" as distro-wide > > policy isn't going to fly. > > I'll implement that if it's all it takes for you to admit that, yes, it's > actually > going to fly. Yes, I'd like to see a reasonable approach for system services. IMHO that approach is "use the firewall", but you don't wanna go that route. So, what else can be done when the user switches networks? (a) start/stop services. Has the disadvantage that they stop listening on the loopback device too, and for some (qemu for example) it isn't a reasonable thing to do. (b) reconfigure services. Have fun implementing that for all the server services fedora has. (c) teach all those services to listen on dbus & reconfigure themselves. Have fun implementing that for all the server services fedora has. (d) run those services in a sandbox, reconfigure the sandbox. Yea, might work (don't know enough about sandboxes to say for sure). (e) something else? cheers, Gerd -- 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: [POC-change] Fedora packages point of contact updates
Hi, I would like to take ownership of ccache for both el6 and el5: Any objection ? Cheers, Adrien Le 15/12/2014 11:01, nob...@fedoraproject.org a écrit : > Change in package status over the last 168 hours > > > 36 packages were orphaned > - > bash-completion [el6, el5] was orphaned by scop > Programmable completion for Bash > https://admin.fedoraproject.org/pkgdb/package/bash-completion > ccache [el6, el5] was orphaned by scop > C/C++ compiler cache > https://admin.fedoraproject.org/pkgdb/package/ccache > colordiff [el6, el5] was orphaned by scop > Color terminal highlighter for diff files > https://admin.fedoraproject.org/pkgdb/package/colordiff > geronimo-commonj [f21, f19, master, f20] was orphaned by jhernand > CommonJ Specification > https://admin.fedoraproject.org/pkgdb/package/geronimo-commonj > gnurobbo [f21, f20, master] was orphaned by raphgro > Port of an once famous game named Robbo from 1989 > https://admin.fedoraproject.org/pkgdb/package/gnurobbo > hibernate-validator [f21, f19, master, f20] was orphaned by jhernand > Bean Validation 1.1 (JSR 349) Reference Implementation > https://admin.fedoraproject.org/pkgdb/package/hibernate-validator > javasqlite [f20, f21, f19, master, el6, epel7, el5] was orphaned by scop > SQLite Java Wrapper/JDBC Driver > https://admin.fedoraproject.org/pkgdb/package/javasqlite > jboss-annotations-1.1-api [f21, f19, master, f20] was orphaned by jhernand > Common Annotations 1.1 API > https://admin.fedoraproject.org/pkgdb/package/jboss-annotations-1.1-api > jboss-el-2.2-api [f21, f19, master, f20] was orphaned by jhernand > Expression Language 2.2 API > https://admin.fedoraproject.org/pkgdb/package/jboss-el-2.2-api > jboss-jaxb-2.2-api [f21, f19, master, f20] was orphaned by jhernand > Java Architecture for XML Binding 2.2 > https://admin.fedoraproject.org/pkgdb/package/jboss-jaxb-2.2-api > jboss-jsf-2.1-api [f21, f19, master, f20] was orphaned by jhernand > JavaServer Faces 2.1 API > https://admin.fedoraproject.org/pkgdb/package/jboss-jsf-2.1-api > jboss-jstl-1.2-api [f21, f19, master, f20] was orphaned by jhernand > JSP Standard Template Library 1.2 API > https://admin.fedoraproject.org/pkgdb/package/jboss-jstl-1.2-api > jboss-jts [f19] was orphaned by jhernand > Distributed Transaction Manager > https://admin.fedoraproject.org/pkgdb/package/jboss-jts > jboss-metadata [f21, f19, master, f20] was orphaned by jhernand > JBoss Metadata > https://admin.fedoraproject.org/pkgdb/package/jboss-metadata > jboss-rmi-1.0-api [f21, f19, master, f20] was orphaned by jhernand > Java Remote Method Invocation 1.0 API > https://admin.fedoraproject.org/pkgdb/package/jboss-rmi-1.0-api > jboss-saaj-1.3-api [f21, f19, master, f20] was orphaned by jhernand > SOAP with Attachments API for Java 1.3 > https://admin.fedoraproject.org/pkgdb/package/jboss-saaj-1.3-api > maven-anno-plugin [f21, f19, master, f20] was orphaned by jhernand > Maven Annotated Mojo > https://admin.fedoraproject.org/pkgdb/package/maven-anno-plugin > maven-jaxb2-plugin [f21, f19, master, f20] was orphaned by jhernand > Provides the capability to generate java sources from schemas > https://admin.fedoraproject.org/pkgdb/package/maven-jaxb2-plugin > mojarra [f21, f19, master, f20] was orphaned by jhernand > JSF Reference Implementation > https://admin.fedoraproject.org/pkgdb/package/mojarra > pyftpdlib [f21, f19, master, f20] was orphaned by silas > Python FTP server library > https://admin.fedoraproject.org/pkgdb/package/pyftpdlib > pymongo [el6, el5] was orphaned by silas > Python driver for MongoDB > https://admin.fedoraproject.org/pkgdb/package/pymongo > python-asyncmongo [master, f21, f19, el6, f20] was orphaned by silas > An asynchronous Python MongoDB library > https://admin.fedoraproject.org/pkgdb/package/python-asyncmongo > python-gevent [f21, f19, master, f20] was orphaned by silas > A coroutine-based Python networking library > https://admin.fedoraproject.org/pkgdb/package/python-gevent > python-gflags [f20, f21, f19, master, el6, el5] was orphaned by silas > Commandline flags module for Python > https://admin.fedoraproject.org/pkgdb/package/python-gflags > python-lockfile [el5] was orphaned by silas > A platform-independent file locking module > https://admin.fedoraproject.org/pkgdb/package/python-lockfile > python-mox [f20, f21, f19, master, el6, epel7, el5] was orphaned by silas > Mock object framework > https://admin.fedoraproject.org/pkgdb/package/python-mox > python-redis [f20, f21, f19, master, el6, epel7, el5] was orphaned by silas > Python 2 interface to the Redis key-value store > https://admin.fedoraproject.org/pkgdb/package/python-redis > python-ssh [f19, f2
Mail bounces: akozu...@redhat.com
Hi,
Bugzilla mails addressed at
dnf-ow...@fedoraproject.org rsp. akozu...@redhat.com
seem to bounce.
Shouldn't this be a temporary hickup (To my best knowledge it is not),
I'd ask those who can do something about it (bugzilla, pkgdb, dnf
maintainers) please take action.
Thanks,
Ralf
Forwarded Message
Subject: Undelivered Mail Returned to Sender
Date: Fri, 19 Dec 2014 09:21:35 + (UTC)
From: Mail Delivery System
To: corse...@fedoraproject.org
This is the mail system at host bastion01.phx2.fedoraproject.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
(expanded from ): host
ext-mx.corp.redhat.com[10.4.123.10] said: 550 5.2.1
... Mailbox disabled for this recipient (in
reply to
RCPT TO command)
Reporting-MTA: dns; bastion01.phx2.fedoraproject.org
X-Postfix-Queue-ID: B8B196087804
X-Postfix-Sender: rfc822; corsepiu@fedoraproject.org
Arrival-Date: Fri, 19 Dec 2014 09:21:34 + (UTC)
Final-Recipient: rfc822; akozumpl@redhat.com
Original-Recipient: rfc822;dnf-owner@fedoraproject.org
Action: failed
Status: 5.2.1
Remote-MTA: dns; ext-mx.corp.redhat.com
Diagnostic-Code: smtp; 550 5.2.1 ... Mailbox disabled for
this recipient
--- Begin Message ---
commit 1e2260e4910901233c187bfdb5332329488b62ca
Author: Ralf Corsépius
Date: Fri Dec 19 10:14:42 2014 +0100
Own %{configdir}/protected.d (RHBZ#1175098).
dnf.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/dnf.spec b/dnf.spec
index 38ca2d0..961e193 100644
--- a/dnf.spec
+++ b/dnf.spec
@@ -8,7 +8,7 @@
Name: dnf
Version:0.6.3
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Package manager forked from Yum, using libsolv as a dependency
resolver
Group: System Environment/Base
# For a breakdown of the licensing, see PACKAGE-LICENSING
@@ -139,6 +139,7 @@ popd
%dir %{confdir}
%dir %{pluginconfpath}
%config(noreplace) %{confdir}/dnf.conf
+%dir %{confdir}/protected.d
%config(noreplace) %{confdir}/protected.d/dnf.conf
%config(noreplace) %{_sysconfdir}/logrotate.d/%{name}
%ghost %{_localstatedir}/log/%{name}.log
@@ -193,6 +194,8 @@ popd
%systemd_postun_with_restart dnf-automatic.timer
%changelog
+* Fri Dec 19 2014 Ralf Corsepius - 0.6.3-3
+- Own %%{configdir}/protected.d (RHBZ#1175098).
* Mon Dec 8 2014 Jan Silhan - 0.6.3-2
- logging: reverted naming from a6dde81
--- End Message ---
--
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: Mail bounces: akozu...@redhat.com
On Fri, Dec 19, 2014 at 10:44:12AM +0100, Ralf Corsepius wrote: > Hi, > > Bugzilla mails addressed at > dnf-ow...@fedoraproject.org rsp. akozu...@redhat.com > seem to bounce. > > Shouldn't this be a temporary hickup (To my best knowledge it is not), I'd > ask those who can do something about it (bugzilla, pkgdb, dnf maintainers) > please take action. As far as I can see the options are: a) Contact Ales and ask him to change his email in FAS b) Remove Ales' ACLs in pkgdb One not being incompatible with the other, but I think option a would be nice to do whether or not option b is applied. 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
rawhide report: 20141219 changes
Compose started at Fri Dec 19 05:15:03 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6 [boswars] boswars-2.7-5.fc22.i686 requires libtolua++-5.1.so [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [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 [ember] ember-0.7.2-2.fc22.i686 requires libtolua++-5.1.so [fawkes] fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-katana-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-pantilt-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires libtolua++-5.1.so [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [google-roboto-fonts] google-roboto-condensed-fonts-1.2-6.fc22.noarch requires google-roboto-common = 0:1.2-6.fc22 [gtatool] gtatool-dcmtk-1.5.2-14.fc22.i686 requires libofstd.so.3.6 gtatool-dcmtk-1.5.2-14.fc22.i686 requires liboflog.so.3.6 gtatool-dcmtk-1.5.2-14.fc22.i686 requires libijg8.so.3.6 gtatool-dcmtk-1.5.2-14.fc22.i686 requires libijg16.so.3.6 gtatool-dcmtk-1.5.2-14.fc22.i686 requires libijg12.so.3.6 gtatool-dcmtk-1.5.2-14.fc22.i686 requires libdcmjpeg.so.3.6 gtatool-dcmtk-1.5.2-14.fc22.i686 requires libdcmimgle.so.3.6 gtatool-dcmtk-1.5.2-14.fc22.i686 requires libdcmdata.so.3.6 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) < 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [stratagus] stratagus-2.2.7-4.fc22.i686 requires libtolua++-5.1.so [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libofstd.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires liboflog.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libijg8.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libijg16.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libijg12.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmnet.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmjpeg.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmimgle.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmimage.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmdata.so.3.6()(64bit) [boswars] boswars-2.7-5.fc22.x86_64 requires libtolua++-5.1.so()(64bit) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.x86_64 requires libval-threads.so.14()(64bit) dnssec-check-1.14.0.1-4.fc20.x86_64 requires libsres.so.14()(64bit) [ember]
Re: Sponsorship request
On Fri, Dec 19, 2014 at 2:38 AM, Vladimir Stackov wrote: > Greetings, Fedora developers, > > I'm coming to you with one small request: > I'm asking you for a sponsorship for this review request: > https://bugzilla.redhat.com/show_bug.cgi?id=1172525 > I understand that I'm somewhat obsessive but counting on your patience :) > > Thanks! > > -- > King regards, > Vladimir. Have you actually found this kind of "pick and choose" deduplication in your backup software to be effective? I've generally found that the integral hard-linking across backups of tools like "rsnapshot" to be much more effective, and if you need to use compressed backups or tape for archival storage, the stability and long lifespan and tape backup support of tools like AMANDA to be more reliable than the creation of Yet Another Incompatible Backup Paradigm(tm) which lacks some of their features. The need to pick and choose and re-assemble components among the tarballs is one that's historically prone to errors among backups. It's not a moral objection to the approach, but wondering "why is it needed"? AMANDA already does incremental tarball backups, it can support encryption, it supports tape drive backup quite effectively, and it has commercial support available for more complex environments with the ZMANDA company. And rsnapshot does very effective de-duplicated full mirrors which can be NFS read-only exported for clients to recover their own files: this has been invaluable for allowing users to recover their files without having to provide sophisticated admin access to the backup syste. So I'm not sure why you need yet another tool. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Base Design WG agenda meeting 19 December 2014 15:00 UTC on #fedora-meeting
Agenda: - Status buildrequires cleanup work (davids & nils!) - Docker update / Rocket container check - Status rpm mechanisms for multiple config subpackages - Status rpm mechanisms for factory reset files - Base WG ownership of generic network install images (agreed already by most, just want confirmation from the last members for acceptance) - Happy holidays! - Open Floor 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
FreeRDP rawhide rebuild
FreeRDP is dropping monolithic builds in the latest release: https://github.com/FreeRDP/FreeRDP/commit/0313ca3622baec53425b749e65caa202015894de All these libraries are no longer available. libfreerdp-cache.so.1.2()(64bit) libfreerdp-codec.so.1.2()(64bit) libfreerdp-common.so.1.2.0()(64bit) libfreerdp-core.so.1.2()(64bit) libfreerdp-crypto.so.1.2()(64bit) libfreerdp-gdi.so.1.2()(64bit) libfreerdp-locale.so.1.2()(64bit) libfreerdp-primitives.so.1.2()(64bit) libfreerdp-rail.so.1.2()(64bit) libfreerdp-utils.so.1.2()(64bit) I will rebuild Remmina and Guacamole; but a a rebuild of Weston and Vinagre is required. Thanks, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.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: Sponsorship request
Greetings, you should probably read zbackup description (available on http://zbackup.org/) and perform backup/restore on multiple VM images. All software that you are talking about (rdiff-backup, rsnapshot, amanda, backuppc, bacula and tons of homegrown "bash backup systems") does not provide real deduplication. All of that symlinks/hardlinks tricks isn't deduplication at all. We use a 64-bit modified Rabin-Karp rolling hash with sliding window that performs checking with a single-byte granularity. It was even better than ZFS deduplication. Take a try and then we will talk about "Yet Another Incompatible Backup Paradigm(tm)" that you will probably pronounce as "next-gen backup paradigm" after you will give a try ;) Yep, not "first next-gen backup paradigm" but "one of two opensource next-gen backup software" because all other software that performs deduplication with sliding window was closed-source proprietary systems. Thanks! 2014-12-19 16:40 GMT+03:00 Nico Kadel-Garcia : > > On Fri, Dec 19, 2014 at 2:38 AM, Vladimir Stackov > wrote: > > Greetings, Fedora developers, > > > > I'm coming to you with one small request: > > I'm asking you for a sponsorship for this review request: > > https://bugzilla.redhat.com/show_bug.cgi?id=1172525 > > I understand that I'm somewhat obsessive but counting on your patience :) > > > > Thanks! > > > > -- > > King regards, > > Vladimir. > > Have you actually found this kind of "pick and choose" deduplication > in your backup software to be effective? I've generally found that the > integral hard-linking across backups of tools like "rsnapshot" to be > much more effective, and if you need to use compressed backups or tape > for archival storage, the stability and long lifespan and tape backup > support of tools like AMANDA to be more reliable than the creation of > Yet Another Incompatible Backup Paradigm(tm) which lacks some of their > features. The need to pick and choose and re-assemble components > among the tarballs is one that's historically prone to errors among > backups. > > It's not a moral objection to the approach, but wondering "why is it > needed"? AMANDA already does incremental tarball backups, it can > support encryption, it supports tape drive backup quite effectively, > and it has commercial support available for more complex environments > with the ZMANDA company. And rsnapshot does very effective > de-duplicated full mirrors which can be NFS read-only exported for > clients to recover their own files: this has been invaluable for > allowing users to recover their files without having to provide > sophisticated admin access to the backup syste. So I'm not sure why > you need yet another tool. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Kind regards, Vladimir. -- 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: Sponsorship request
In addition to my previous message: Take a look on ddar vs rdiff-backup comparison: https://github.com/basak/ddar/wiki/rdiff-backup Most of those concepts are applicable to zbackup. 2014-12-19 17:30 GMT+03:00 Vladimir Stackov : > > Greetings, > > you should probably read zbackup description (available on > http://zbackup.org/) and perform backup/restore on multiple VM images. > > All software that you are talking about (rdiff-backup, rsnapshot, amanda, > backuppc, bacula and tons of homegrown "bash backup systems") does not > provide real deduplication. > All of that symlinks/hardlinks tricks isn't deduplication at all. > We use a 64-bit modified Rabin-Karp rolling hash with sliding window that > performs checking with a single-byte granularity. It was even better than > ZFS deduplication. > Take a try and then we will talk about "Yet Another Incompatible Backup > Paradigm(tm)" that you will probably pronounce as "next-gen backup > paradigm" after you will give a try ;) > > Yep, not "first next-gen backup paradigm" but "one of two opensource > next-gen backup software" because all other software that performs > deduplication with sliding window was closed-source proprietary systems. > > Thanks! > > 2014-12-19 16:40 GMT+03:00 Nico Kadel-Garcia : >> >> On Fri, Dec 19, 2014 at 2:38 AM, Vladimir Stackov >> wrote: >> > Greetings, Fedora developers, >> > >> > I'm coming to you with one small request: >> > I'm asking you for a sponsorship for this review request: >> > https://bugzilla.redhat.com/show_bug.cgi?id=1172525 >> > I understand that I'm somewhat obsessive but counting on your patience >> :) >> > >> > Thanks! >> > >> > -- >> > King regards, >> > Vladimir. >> >> Have you actually found this kind of "pick and choose" deduplication >> in your backup software to be effective? I've generally found that the >> integral hard-linking across backups of tools like "rsnapshot" to be >> much more effective, and if you need to use compressed backups or tape >> for archival storage, the stability and long lifespan and tape backup >> support of tools like AMANDA to be more reliable than the creation of >> Yet Another Incompatible Backup Paradigm(tm) which lacks some of their >> features. The need to pick and choose and re-assemble components >> among the tarballs is one that's historically prone to errors among >> backups. >> >> It's not a moral objection to the approach, but wondering "why is it >> needed"? AMANDA already does incremental tarball backups, it can >> support encryption, it supports tape drive backup quite effectively, >> and it has commercial support available for more complex environments >> with the ZMANDA company. And rsnapshot does very effective >> de-duplicated full mirrors which can be NFS read-only exported for >> clients to recover their own files: this has been invaluable for >> allowing users to recover their files without having to provide >> sophisticated admin access to the backup syste. So I'm not sure why >> you need yet another tool. >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > -- > Kind regards, > Vladimir. > -- Kind regards, Vladimir. -- 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: kvm: vcpu unhandled rdmsr:
On 19/12/2014 16:44, poma wrote: > Mister Bonzini, what are these errors? They are harmless. Typically it means that the VM is trying to access registers for performance counters or machine check exceptions. Instead, this: > [ 125.880384] kvm: zapping shadow pages for mmio generation wraparound should be downgraded to KERN_DEBUG severity. > [ 4011.896698] kvm: zapping shadow pages for mmio generation wraparound > [ 4046.744577] kvm [4706]: vcpu0 unhandled rdmsr: 0xc0010112 > [ 4046.815794] kvm [4706]: vcpu0 unhandled rdmsr: 0xc001100d > [ 4046.949092] kvm [4706]: vcpu0 unhandled rdmsr: 0xc0010001 > [ 4046.962165] kvm [4706]: vcpu1 unhandled rdmsr: 0xc001100d > > Both Fedora 21 x64 host & Fedora 21 x64 guest are hosed, hard reset is must. It should not be hosed because of the rdmsr. What processor do you have in the host? Can you include the output of "ps | grep qemu"? 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
kvm: vcpu unhandled rdmsr:
Mister Bonzini, what are these errors? [ 15.211466] kvm: Nested Virtualization enabled [ 15.211653] kvm: Nested Paging enabled [ 125.880384] kvm: zapping shadow pages for mmio generation wraparound [ 137.947340] kvm [2188]: vcpu0 unhandled rdmsr: 0xc0010112 [ 138.074999] kvm [2188]: vcpu0 unhandled rdmsr: 0xc001100d [ 138.215100] kvm [2188]: vcpu0 unhandled rdmsr: 0xc0010001 [ 138.229484] kvm [2188]: vcpu1 unhandled rdmsr: 0xc001100d [ 208.887308] kvm: zapping shadow pages for mmio generation wraparound [ 247.756864] kvm [2467]: vcpu0 unhandled rdmsr: 0xc0010112 [ 247.872103] kvm [2467]: vcpu0 unhandled rdmsr: 0xc001100d [ 248.007530] kvm [2467]: vcpu0 unhandled rdmsr: 0xc0010001 [ 248.022243] kvm [2467]: vcpu1 unhandled rdmsr: 0xc001100d [ 2373.089351] kvm: zapping shadow pages for mmio generation wraparound [ 2378.807097] kvm [3114]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2378.879543] kvm [3114]: vcpu0 unhandled rdmsr: 0xc001100d [ 2379.010716] kvm [3114]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2379.023819] kvm [3114]: vcpu1 unhandled rdmsr: 0xc001100d [ 2555.311726] kvm: zapping shadow pages for mmio generation wraparound [ 2557.884005] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2557.956526] kvm [3354]: vcpu0 unhandled rdmsr: 0xc001100d [ 2558.087764] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2558.100915] kvm [3354]: vcpu1 unhandled rdmsr: 0xc001100d [ 2571.622172] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2571.689491] kvm [3354]: vcpu0 unhandled rdmsr: 0xc001100d [ 2571.820737] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2571.833627] kvm [3354]: vcpu1 unhandled rdmsr: 0xc001100d [ 2596.645621] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2596.711569] kvm [3354]: vcpu0 unhandled rdmsr: 0xc001100d [ 2596.842047] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2596.855041] kvm [3354]: vcpu1 unhandled rdmsr: 0xc001100d [ 2606.305324] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2606.373913] kvm [3354]: vcpu0 unhandled rdmsr: 0xc001100d [ 2606.505235] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2606.518368] kvm [3354]: vcpu1 unhandled rdmsr: 0xc001100d [ 2646.290948] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2646.362594] kvm [3354]: vcpu0 unhandled rdmsr: 0xc001100d [ 2646.493929] kvm [3354]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2646.507061] kvm [3354]: vcpu1 unhandled rdmsr: 0xc001100d [ 2671.850396] kvm: zapping shadow pages for mmio generation wraparound [ 2681.818148] kvm: zapping shadow pages for mmio generation wraparound [ 2683.390247] kvm [3853]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2683.462436] kvm [3853]: vcpu0 unhandled rdmsr: 0xc001100d [ 2683.593449] kvm [3853]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2683.606514] kvm [3853]: vcpu1 unhandled rdmsr: 0xc001100d [ 2706.920179] kvm: zapping shadow pages for mmio generation wraparound [ 2741.850111] kvm [4049]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2741.922049] kvm [4049]: vcpu0 unhandled rdmsr: 0xc001100d [ 2742.053190] kvm [4049]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2742.066333] kvm [4049]: vcpu1 unhandled rdmsr: 0xc001100d [ 2914.712545] kvm [4049]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2914.780266] kvm [4049]: vcpu0 unhandled rdmsr: 0xc001100d [ 2914.911599] kvm [4049]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2914.924873] kvm [4049]: vcpu1 unhandled rdmsr: 0xc001100d [ 2924.352967] kvm: zapping shadow pages for mmio generation wraparound [ 2928.710690] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010112 [ 2928.780477] kvm [4270]: vcpu0 unhandled rdmsr: 0xc001100d [ 2928.911702] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010001 [ 2928.924767] kvm [4270]: vcpu1 unhandled rdmsr: 0xc001100d [ 3035.293310] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010112 [ 3035.360315] kvm [4270]: vcpu0 unhandled rdmsr: 0xc001100d [ 3035.490647] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010001 [ 3035.503761] kvm [4270]: vcpu1 unhandled rdmsr: 0xc001100d [ 3054.646321] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010112 [ 3054.714035] kvm [4270]: vcpu0 unhandled rdmsr: 0xc001100d [ 3054.844396] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010001 [ 3054.857537] kvm [4270]: vcpu1 unhandled rdmsr: 0xc001100d [ 3214.655214] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010112 [ 3214.723057] kvm [4270]: vcpu0 unhandled rdmsr: 0xc001100d [ 3214.854429] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010001 [ 3214.867564] kvm [4270]: vcpu1 unhandled rdmsr: 0xc001100d [ 3232.252017] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010112 [ 3232.318695] kvm [4270]: vcpu0 unhandled rdmsr: 0xc001100d [ 3232.449035] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010001 [ 3232.462150] kvm [4270]: vcpu1 unhandled rdmsr: 0xc001100d [ 3653.126758] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010112 [ 3653.195737] kvm [4270]: vcpu0 unhandled rdmsr: 0xc001100d [ 3653.326077] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010001 [ 3653.339204] kvm [4270]: vcpu1 unhandled rdmsr: 0xc001100d [ 3665.730480] kvm [4270]: vcpu0 unhandled rdmsr: 0xc0010112 [ 3665.797924] kvm [4270]: vcpu0 unhandled rdmsr: 0xc001100d [ 3665.928272] kvm [
Planned Outage: koji buildsystem - 2014-12-22 20:00 UTC
Planned Outage: koji buildsystem - 2014-12-22 20:00 UTC There will be an outage starting at 2014-12-22 20:00 UTC, which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2014-12-22 20:00 UTC' Reason for outage: The blade server hosting the koji buildsystem and it's database server will be having wiring work as well as firmware upgrades performed. The koji hub, it's database and a number of builders will all be down during this outage window. Affected Services: Buildsystem - http://koji.fedoraproject.org/ Unaffected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ GIT / Source Control - pkgs.fedoraproject.org Darkserver - https://darkserver.fedoraproject.org/ DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Elections - https://admin.fedoraproject.org/voting Email system Fedmsg busmon - http://apps.fedoraproject.org/busmon Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Calendar - https://apps.fedoraproject.org/calendar/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4628 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. pgpFyS2W_Yj6U.pgp Description: OpenPGP digital signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- 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: Qwt and QwtPolar for Qt5?
Dave Johansen wrote: > Should it just be a separate package > called qwt-qt5 in EPEL 6 yes, +1 -- Rex -- 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: Sponsorship request
On 12/19/2014 08:38 AM, Vladimir Stackov wrote: > Greetings, Fedora developers, > > I'm coming to you with one small request: > I'm asking you for a sponsorship for this review request: > https://bugzilla.redhat.com/show_bug.cgi?id=1172525 > I understand that I'm somewhat obsessive but counting on your patience :) I've taken the review and I will sponsor you. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: Sponsorship request
Thank you! 2014-12-20 0:22 GMT+03:00 Mikolaj Izdebski : > > On 12/19/2014 08:38 AM, Vladimir Stackov wrote: > > Greetings, Fedora developers, > > > > I'm coming to you with one small request: > > I'm asking you for a sponsorship for this review request: > > https://bugzilla.redhat.com/show_bug.cgi?id=1172525 > > I understand that I'm somewhat obsessive but counting on your patience :) > > I've taken the review and I will sponsor you. > > -- > Mikolaj Izdebski > Software Engineer, Red Hat > IRC: mizdebsk > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- Kind regards, Vladimir. -- 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: kvm: vcpu unhandled rdmsr:
On 19.12.2014 18:33, Paolo Bonzini wrote: > > > On 19/12/2014 16:44, poma wrote: >> Mister Bonzini, what are these errors? > > They are harmless. Typically it means that the VM is trying to access > registers for performance counters or machine check exceptions. > > Instead, this: > >> [ 125.880384] kvm: zapping shadow pages for mmio generation wraparound > > should be downgraded to KERN_DEBUG severity. > >> [ 4011.896698] kvm: zapping shadow pages for mmio generation wraparound >> [ 4046.744577] kvm [4706]: vcpu0 unhandled rdmsr: 0xc0010112 >> [ 4046.815794] kvm [4706]: vcpu0 unhandled rdmsr: 0xc001100d >> [ 4046.949092] kvm [4706]: vcpu0 unhandled rdmsr: 0xc0010001 >> [ 4046.962165] kvm [4706]: vcpu1 unhandled rdmsr: 0xc001100d >> >> Both Fedora 21 x64 host & Fedora 21 x64 guest are hosed, hard reset is must. > > It should not be hosed because of the rdmsr. > > What processor do you have in the host? Can you include the output of > "ps | grep qemu"? > > Paolo > Eccola Mister Bonzini, $ ps | grep qemu ; echo $? 1 $ ps axu | grep [q]emu ; echo $? qemu 2347 101 1.6 2951384 63144 ? Sl 21:33 8:41 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name Fedora21 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Opteron_G3,+wdt,+skinit,+ibs,+osvw,+3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+3dnow,+3dnowext,+pdpe1gb,+fxsr_opt,+mmxext,+ht,+vme -m 2024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 ... 0 /etc/libvirt/qemu/Fedora21.xml ... ... 2 hvm ... ... HOST: /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : AMD Phenom(tm) II X4 955 Processor stepping: 3 microcode : 0x1c8 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save vmmcall bugs: tlb_mmatch apic_c1e fxsave_leak bogomips: 6400.37 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate ... "Phenom" doesn't exist in the /usr/share/libvirt/cpu_map.xml, therefore libvirt? chooses probably the closest to specification, and it is always Opteron_G3, even if cpu mode='host-passthrough'. Is this the culprit, dunno, but both systems do have a tendency to "hose". And this is nothing new, it is ongoing long since. GUEST: /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 6 model name : AMD Opteron 23xx (Gen 3 Class Opteron) stepping: 1 microcode : 0x165 cpu MHz : 3199.998 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 x2apic popcnt hypervisor cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw vmmcall bugs: fxsave_leak bogomips: 6399.99 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ... -- 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: Mail bounces: akozu...@redhat.com
On Fri, Dec 19, 2014 at 3:35 AM, Pierre-Yves Chibon wrote: > On Fri, Dec 19, 2014 at 10:44:12AM +0100, Ralf Corsepius wrote: >> Hi, >> >> Bugzilla mails addressed at >> dnf-ow...@fedoraproject.org rsp. akozu...@redhat.com >> seem to bounce. >> >> Shouldn't this be a temporary hickup (To my best knowledge it is not), I'd >> ask those who can do something about it (bugzilla, pkgdb, dnf maintainers) >> please take action. > > As far as I can see the options are: > > a) Contact Ales and ask him to change his email in FAS > b) Remove Ales' ACLs in pkgdb > One not being incompatible with the other, but I think option a would be nice > to > do whether or not option b is applied. Ales Kozumplik is no longer DNF maintainer, he handed it off to Jan Šilhan . http://dnf.baseurl.org/2014/09/18/new-dnf-project-leader/ -- 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: Mail bounces: akozu...@redhat.com
On 12/20/2014 02:46 AM, Chris Murphy wrote: On Fri, Dec 19, 2014 at 3:35 AM, Pierre-Yves Chibon wrote: On Fri, Dec 19, 2014 at 10:44:12AM +0100, Ralf Corsepius wrote: Hi, Bugzilla mails addressed at dnf-ow...@fedoraproject.org rsp. akozu...@redhat.com seem to bounce. Shouldn't this be a temporary hickup (To my best knowledge it is not), I'd ask those who can do something about it (bugzilla, pkgdb, dnf maintainers) please take action. As far as I can see the options are: a) Contact Ales and ask him to change his email in FAS b) Remove Ales' ACLs in pkgdb One not being incompatible with the other, but I think option a would be nice to do whether or not option b is applied. Ales Kozumplik is no longer DNF maintainer, he handed it off to Jan Šilhan . http://dnf.baseurl.org/2014/09/18/new-dnf-project-leader/ OK, but then some overseer/RH-manager, bugzilla/pkgdb-maintainer or may-be the new package maintainer should reflect this to the pkgdb and/or bugzilla. At least until yesterday, dnf-ow...@fedoraproject.org seems to have pointed to akoz...@redhat.com ;) In this context, I also would suggest, RH to consider improving their "quitting"/"employee checkout" process to cover pkgdb/bugzilla. Ralf -- 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: Mail bounces: akozu...@redhat.com
Hi, On Sat, Dec 20, 2014 at 10:07 AM, Ralf Corsepius wrote: > On 12/20/2014 02:46 AM, Chris Murphy wrote: >> >> On Fri, Dec 19, 2014 at 3:35 AM, Pierre-Yves Chibon >> wrote: >>> >>> On Fri, Dec 19, 2014 at 10:44:12AM +0100, Ralf Corsepius wrote: Hi, Bugzilla mails addressed at dnf-ow...@fedoraproject.org rsp. akozu...@redhat.com seem to bounce. Shouldn't this be a temporary hickup (To my best knowledge it is not), I'd ask those who can do something about it (bugzilla, pkgdb, dnf maintainers) please take action. >>> >>> >>> As far as I can see the options are: >>> >>> a) Contact Ales and ask him to change his email in FAS >>> b) Remove Ales' ACLs in pkgdb >>> One not being incompatible with the other, but I think option a would be >>> nice to >>> do whether or not option b is applied. >> >> >> >> Ales Kozumplik is no longer DNF maintainer, he >> handed it off to Jan Šilhan . >> http://dnf.baseurl.org/2014/09/18/new-dnf-project-leader/ > > > OK, but then some overseer/RH-manager, bugzilla/pkgdb-maintainer or may-be > the new package maintainer should reflect this to the pkgdb and/or bugzilla. > At least until yesterday, dnf-ow...@fedoraproject.org seems to have pointed > to akoz...@redhat.com ;) > > In this context, I also would suggest, RH to consider improving their > "quitting"/"employee checkout" process to cover pkgdb/bugzilla. Generally I have seen sometimes when a RH employee quits, his packages gets re-assigned to some peer or its manager. This can be easily seen by bugzilla notifications where bugs gets reassigned. When Ales quit, I thought this bugzilla script will be run (not sure who triggers this script) but that did not happen. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
