Re: Red Hat and Fedora Working Groups
On Sat, Oct 05, 2013 at 03:29:57AM +, "Jóhann B. Guðmundsson" wrote: > Shall we talk about how Red Hat employees have been granted all > kinds of privileges within our community without as even bother to > introduce themselves to the community even to the extent that fesco > is now judging people if they are "socially ready" for proven > packagers while Red Hat employees walk around and are granted those > privileges freely? That is an utter fabrication. Red Hat packagers have to go exactly through the same process to became packagers as anyone else (well, it may be easier for them to find a sponsor, but sponsored they must be); they have to go through the same process to became proven packagers etc. I respectfully suggest that you be silent if you do not know the facts. Your credibility is diminishing rapidly with every untrue statement you put forth. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
License change for pgRouting 2.0.0
Hi! pgRouting is no longer under "GPLv2+ and Boost": The components under Boost license were removed and thus the resulting license is GPLv2+. Greetings, Volker Fröhlich -- 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: rawhide report: 20131006 changes
2013/10/7 Jerry James : > On Sun, Oct 6, 2013 at 7:36 AM, Fedora Rawhide Report > wrote: >> sagemath-5.10-2.fc21 >> >> * Fri Oct 04 2013 pcpa - 5.10-2 >> - Rebuild with newer rawhide atlas. > > The previous version of sagemath was 5.10-4. Why did the release > number go backwards? I messed things up, due to several build trees and not paying as much attention as I should, while attempting to do too many things at the same time, and updating sagemath while waiting some builds... I can resubmit it. In the meantime, if you could review the libgap bug report it would help a lot, for sagemath 5.11 it is not optional. > -- > Jerry James > http://www.jamezone.org/ Paulo -- 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: rawhide report: 20131006 changes
On Sun, Oct 6, 2013 at 7:36 AM, Fedora Rawhide Report wrote: > sagemath-5.10-2.fc21 > > * Fri Oct 04 2013 pcpa - 5.10-2 > - Rebuild with newer rawhide atlas. The previous version of sagemath was 5.10-4. Why did the release number go backwards? -- Jerry James http://www.jamezone.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
[Owner-change] Fedora packages ownership change
Change in ownership over the last 168 hours === 2 packages were orphaned pystatgrab [devel,f19,f20] was orphaned by fab Python bindings for libstatgrab https://admin.fedoraproject.org/pkgdb/acls/name/pystatgrab tbb [EL-5] was orphaned by orion The Threading Building Blocks library abstracts low-level threading details https://admin.fedoraproject.org/pkgdb/acls/name/tbb 2 packages unorphaned - puiterwijk unorphaned : lybniz [f19] ralph unorphaned : python-zope-interface [devel,f18,f19,f20] 7 packages were retired dkim-milter [EL-5,EL-6,devel,f18,f19,f20] was retired by radford DomainKeys Identified Mail sender authentication sendmail milter https://admin.fedoraproject.org/pkgdb/acls/name/dkim-milter glpi-mass-ocs-import [devel,f20] was retired by remi GLPI Plugin for OCS Massive import https://admin.fedoraproject.org/pkgdb/acls/name/glpi-mass-ocs-import glpi-pdf [devel,f20] was retired by remi GLPI Plugin to print PDF of computers https://admin.fedoraproject.org/pkgdb/acls/name/glpi-pdf python-cjson [devel,f20] was retired by fschwarz Fast JSON encoder/decoder for Python https://admin.fedoraproject.org/pkgdb/acls/name/python-cjson wlmproxy [EL-6] was retired by poetinha An advanced proxy for the MSN Messenger protocol https://admin.fedoraproject.org/pkgdb/acls/name/wlmproxy glpi-data-injection [devel,f20] was retired by remi Plugin for importing data into GLPI https://admin.fedoraproject.org/pkgdb/acls/name/glpi-data-injection django-tables [EL-6,devel,f20] was retired by poetinha A Django Queryset renderer https://admin.fedoraproject.org/pkgdb/acls/name/django-tables 2 packages changed owner limbgave to averi : check-mk [EL-5] limbgave to remi : diffmark [EL-6] Sources: https://github.com/pypingou/fedora-owner-change -- 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: GPG verification in SPECs
Hi Josh, On Thu, Oct 03, 2013 at 10:59:24AM -0400, Josh Bressers wrote: > > upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at > > https://build.opensuse.org/package/show/Base:System/gpg-offline > > > > They allow to use a keyring and detached signature as additional source > > in SPECs to get both verified. Since gpg-offline's upstream is willing > > to create a proper release to allow easy packaging for Fedora, I wonder > > if I will find any obstacles when I package it. The packaging guidelines > > allow packaging RPM macros, therefore this should be fine. > > > > Also I am interested whether there are better options available. > > > > Hi Till, > > Any news on packaging this? I'm interested to see what we can do with it. no, sorry, I did not get any further, yet. Regards Till -- 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: Red Hat and Fedora Working Groups
Am 06.10.2013 22:18, schrieb Jóhann B. Guðmundsson: > On 10/05/2013 07:08 AM, Mathieu Bridon wrote: >> >> So every time you say that, I can't help thinking you're just jealous they >> took someone « outside the community » >> instead of you. >> >> It might not be what you're thinking, but it's really how you sound. >> >> Maybe those « individuals » are just more competent? Or you know, maybe Red >> Hat prefers hiring people who don't >> spend their time vomiting their hatred on mailing-lists? > > You are making the assumption that Red Hat has not already offered me a job > as well as the fact that I would > associate my name to a company when behaves like this. > > Good for you... *what* exactly is your problem with Redhat? i am always the bad-ass because my hard opinions about wrong technical decisions, well so it may be, but what you are doing all the time is fight against a company because it is a company without realize what Redhat is doing for the open source ecosystem over many years do you not realize that without Redhat Fedora would not exist at all and *nobody* but you is interested in Fedora without Redhat? 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: sysctl behavior for docker-io
On Mon, Oct 07, 2013 at 10:06:51AM +0100, Daniel P. Berrange wrote: > We really only wanted to enable forwarding from virbr0, to the LAN, but > you can't toggle this per NIC afaick - you have to turn on the global There seems to be per-NIC settings at: /proc/sys/net/ipv*/conf/*/forwarding Regards Till -- 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: AutoQA ??? (was: Re: Building and submitting updates for Fedora 20)
Right, Tim fixed the issue and updates in Bodhi should once again receive comments regarding "depcheck" and "upgradepath" checks. There's an opt-in support for rpmlint/rpmguard checks for every package built (the emails are sent to their maintainers), but I'm not clear whether this opt-in support works at all. In any case, the results can always be found using the web interface: http://autoqa.fedoraproject.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
dnf-0.4.3 released
Hello, Because the "Too many open files" bug came back[1] and up until now DNF had to be released in lockstep with librepo, the new build is coming out earlier than expected. Please see the release notes [2] and a blog post [3] about the release where I go into details why we no longer depend on a concrete versions of libraries below DNF. Ales [1] https://bugzilla.redhat.com/show_bug.cgi?id=1015957 [2] http://dnf.baseurl.org/?p=36 [3] http://akozumpl.github.io/dnf/release_notes.html#id14 -- 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: sysctl behavior for docker-io
On Mon, Oct 07, 2013 at 10:06:51AM +0100, Daniel P. Berrange wrote: > On Sun, Oct 06, 2013 at 07:25:50PM -0400, Matthew Miller wrote: > > On Sun, Oct 06, 2013 at 11:32:13PM +0200, Lennart Poettering wrote: > > > Or in other words: I don't think it makes much sense to turn this on > > > only at runtime inside the service file as matthew suggests, as it hides > > > the fact that the setting is made, makes it hard for admins to discover > > > and override it, and creates the assumption that the package would turn > > > off the setting safely again after the daemon exited, but which it > > > doesn't and can't since it doesn't know if anything else still requires > > > it. > > > Hope that makes some sense, > > > > It does make some sense; overall I don't think there's a really good answer > > here. In trying to figure out what's the most sensible given that, I looked > > at what libvirt does, which is turn it on globally in exactly the hidden way > > you suggest, and makes no attempt to restore it. I'm not really excited > > about that, but apparently that's been the case for a while. > > Yeah, what libvirt does is really not very nice. If you want to use a > routed networking setup though, I don't know of any better options for > making this work. > > We really only wanted to enable forwarding from virbr0, to the LAN, but > you can't toggle this per NIC afaick - you have to turn on the global > ip_forwarding sysctl. Libvirt just turns it on when first creating its > NAT'd device, which for most installs will be at boot time when libvirtd > starts. Another way to look at it might be: Since a lot of people have libvirt installed (it's the default isn't it?) and hence forwarding has been on for many people for a long time, what harm is it causing? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones 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: Red Hat and Fedora Working Groups
Quoting Jóhann B. Guðmundsson (2013-10-05 05:29:57) > Shall we talk about how Red Hat employees have been granted all kinds of > privileges within our community without as even bother to introduce > themselves to the community even to the extent that fesco is now judging > people if they are "socially ready" for proven packagers while Red Hat > employees walk around and are granted those privileges freely? Your vitriol is not appreciated I want you to point out the person who got provenpackager privileges without going through normal provenpackager process. I have personally seen (and voted against) a few colleagues who wanted to get provenpackager (or sponsor) permissions but didn't have enough experience IMO. As far as I know they are not provenpackagers/sponsors. If this really was a problem I know a lot of Red Hat employees would be as unhappy about this inequality as you seem to be. But it's not... You are actually insulting and attacking integrity of every sponsor (i.e. people who actually vote for/against new provenpackagers). I like Simon Phipps's quote "Corporations are not people". If you have a problem with specific action taken by specific Red Hat employees: point it out! Do not be generic or people will most likely write you off as another troll. -- Stanislav Ochotnicky Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.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
F-20 Branched report: 20131007 changes
Compose started at Mon Oct 7 09:15:03 UTC 2013 Broken deps for armhfp -- [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server >= 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [bwm-ng] bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9 [cloud-init] cloud-init-0.7.2-4.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [fawkes] fawkes-doc-0.5.0-9.fc20.noarch requires fawkes = 0:0.5.0-9.fc20 [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glusterfs] glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift = 0:1.8.0 [gnome-do-plugins] gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) >= 0:0.16.0 [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [grass] grass-6.4.2-11.fc20.armv7hl requires libgeos-3.3.8.so grass-libs-6.4.2-11.fc20.armv7hl requires libgeos-3.3.8.so [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [monotone] monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) [mozilla-firetray] mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires thunderbird >= 0:11 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc >= 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [osm2pgsql] osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [oyranos] oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5 [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-MIME-Lite-HTML] perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [perl-MooseX-TrackDirty-Attributes] perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-Padre] perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [player] player-3.0.2-32.fc20.armv7hl requires libstatgrab.so.9 player-3.0.2-32.fc20.armv7hl requires libgeos-3.3.8.so [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-basemap] python-basemap-1.0.6-4.fc20.armv7hl requires libgeos-3.3.8.so [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [rubygem-audited-activerecord]
Re: Red Hat and Fedora Working Groups
Hi Jóhann, I do agree with you that the interaction between Red Hat and Fedora needs to be clearer, and that currently it is a bit vaguely defined and thus it gives ground to conspiracy theories and feelings of disenfranchisement. That said I think you too need to be open to that Red Hat, like yourself and any other participant in the Fedora project does so because there is a sense of self interest. That self interest may wary from enjoyment of community, to skills building, or to Fedora providing a solution to a technical problem you have. Red Hat is not investing heavily in Fedora in terms of infrastructure and development resources just because we as a company needs a place to spend money, if that was the case I am sure you would agree we should instead donate the money to the Red Cross or similar. The reason Red Hat invests in Fedora is because Fedora plays an important part in both product development and in innovating new technologies. So if Fedora ends up not being interesting or useful to you personally anymore I assume you would leave Fedora behind, the same is true for Red Hat. So I think part of the reason we end up having these kinds of argument it is because for a long time maybe both inside and outside Red Hat there has been a pretense that Red Hat as a company has no direct interest in Fedora and that Red Hats resources and contributions to the project is a given, no matter what. Red Hats involvement in Fedora has somehow become the unspoken of elephant in the room. Maybe what we need to do is instead start speaking openly of why Red Hat wants to be involved with Fedora. So you mention that some Red Hat employees have bypassed processes, and I am sure this has happened, but that is a direct consequence of that Fedora not being a 'random' distro for Red Hat, but an integral part of our product development. I mean there is no secret that RHEL is built from Fedora. The tools used to build Fedora overlap and intermingle with the tools used for building RHEL. So I am not saying that makes everything ok, but what I want to say is that we need to accept that these things doesn't happen out of malice, and work together to find solutions for how they can be handled better going forward in a way that is mutually beneficial and acceptable to all. So there are two solutions to the challenge faced with Red Hat and Fedora. The first option is a decision that Red Hat withdraws from Fedora and tries to build replacements for Fedora current role in our product development. Or that the Fedora community and Red Hat agrees that the current involvement from Red Hat is beneficial to Fedora overall, despite that it comes with some strings attached and that the rules of Fedora might at times collide with the practical concerns of Red Hat, who needs to build products for our customers. And I don't think (almost) anyone inside or outside Red Hat wants solution 1. So maybe everyone involved needs to take a deep breath and accept that there is no 'clean' solution here. There is no rule that can be made that somehow resolves all the complexity of Fedora both being a community project and at the same time a core part of the Red Hat product development workflow and overall market strategy. Sometimes this weird duality will create friction, but we need to discuss and talk calmly about these issues and try to find solutions, instead of assuming bad things of each other. And often if a change ends up being good or bad is a lot up to the participants. If you go into something only looking for reasons why it is bad, then there is a good chance you will end up making it bad, at least for yourself. And at the same time if you approach something as an opportunity to do something positive, your chances of doing that is greatly increased. And often the good solutions is about thinking outside the box a bit. And as a sidenote, I think there is a tendency to brand any discussion about Fedora inside Red Hat as some kind of backroom dealings and skulduggery, but I think this is silly and unfair. Red Hat like any other participant sometimes need to figure out what is the Red Hat position on issues and challenges, a position which might not align with every Fedora community member or every individual Red Hat employee, and Red Hat being a company and not an individual can only reach such positions by discussing them internally first. And to me this is actually beneficial to the Fedora community as it can provide the community with a clear sense of what the official company position is on a given subject, as opposed to trying to somehow extract it from the buzz of various individual Red Hat employees stating a mix of company positions and their private opinions. The real challenge here is to avoid the need to build company positions lead into a default of doing discussions internally that can be just as fine be done in the public with full community involvement. This is a challenge that any project with a big corporate sponsor h
Re: Red Hat and Fedora Working Groups
2013/10/7 "Jóhann B. Guðmundsson" > > Or people turn a blind eye to the facts on what's actually taking place. > > - It places distrust in the community ( as came completely clear on last > FESCO meeting ) > > Fesco members are all elected by contributors (no nominated members by Red Hat), if you think they doesn't do their job properly, you're more than capable to step up at the next election. > - It puts the community to disadvantage compare to it employees which now > as stepped up to the level that community members are subjected to > character and social scrutiny by FESCO ( look at Dan's pp request 3 > meetings ago ) while Red Hat employees entirely bypass that and other ( > privileged ) processes that community members have to go through. > > I don't remember being employed by Red Hat, neither are the other members who were worried that FESCo rushed that pp request. You're completely rewriting history here, because, FESCo approved this pp request without respecting its own guidelines, many voices from the community had intervened to restore legality here. This incident was handled by community sponsors in respect to the process defined by the community, not by Red Hat employees. > - It elevates it's own "product(s)" above community's work either under > the so called "defaults" ( or as we are heading now "3 products" ) or > various strategically placed "recommendations" here and there putting > competing community maintained products at disadvantage. > > One of Fedora's biggest success was to build a strong community that spear-headed the GNU/Linux efforts for years. But we're reaching our own limits and we have to set clear goals to keep this community together. By defining three products (and people are free to propose other products, it's a truly community-driven process), we are setting these goals that will make Fedora works in the future. > - It creates ( high ranking ) positions ( suddenly ) in communities, then > recruits individuals outside the community and places them in those > positions and in those communities ( people can just look through the > internet archive's for advertised Fedora positions both for the title they > give these individuals as well as the statement you will be working as as > opposed to working with ). > > etc... > > I consider the whole Red Hat as a particular contributor, i don't give a rat's ass about anyone position (community manager, cloud architect or whatever). What i consider is the work done by individuals. Off course, Red Hat wants to drive Fedora where are their own interests, but they have as much power as their contributions are worth to the community. I'm not supporting Matthew's proposal because he works at Red Hat but as fellow contributor who did a great job. > So as you can see it already is behaving as I think it behaves and quite > frankly this is an disgusting and unjust corporate behavior towards the > community based on mistrust and misuse and sends mixed signals inside and > outside of our community and labels our work as some kind of RH experiment > and test bed. > > As you, i still resent what Brian Steven said about Fedora being only RHEL sandbox, but we have to keep our heads cool. You have valid arguments (mixed signals sent to the community for instance), please, don't mix everything with unfair arguments. > All of the issues I have mentioned here before can be dealt with > internally by Red Hat. > > - It has to take a leap of faith and just let go and place trust in the > community since it's highly unlikely that it will venture to far away from > Red Hat interest at least I would be very surprised if it did. > > I'm pretty sure that most RH employees involved in Fedora are thinking the same way. > - If it thinks that our processes are to complex for an new employee to > walk through to gain the necessary access to be able to perform it's work, > it needs to work with us improving those processes and workflows so that > *everybody* Red Hat employees and community members alike will gain from it > as opposed to be bypassing it altogether for it's employee while the > community drowns in bureaucracy. > > +1 > - It will need to understand that forcing everything under a single > product ( default ) or three products as well as single audience ( or three > different audience ) hinders growth in sub communities ( due to them not > being equally presented ) as well as fair competition thus innovation > between competing products applications or applications stack ( be it > through better written code/compatibility/features/**maintenance you know > those little things that competing products implement or achieve over each > other ) . > > You're being unfair, this decision has been discussed in the open and has been approved by a fully community process, you were THERE at Flock when we discussed this face to face. > - It needs to understand that there is no need to invent ( high ranking ) > position and try to elevate n
Re: Building and submitting updates for Fedora 20
On 10/06/2013 04:06 PM, Peter Robinson wrote: The following need to be reviewed by the maintainer as there's a number of builds or other issues: plymouth cups-filters I've just submitted cups-filters update. I don't see any issues. -- Jiri -- 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: Red Hat and Fedora Working Groups
On 10/07/2013 08:20 AM, Jaroslav Reznik wrote: - Original Message - >On 10/05/2013 07:08 AM, Mathieu Bridon wrote: I'd say most of Fedora (and even most of Red Hatters) would quit immediately in case the company starts behave like you think it behaves. And I'm saying it as a guy who signed mortgage week ago. Or people turn a blind eye to the facts on what's actually taking place. - It places distrust in the community ( as came completely clear on last FESCO meeting ) - It puts the community to disadvantage compare to it employees which now as stepped up to the level that community members are subjected to character and social scrutiny by FESCO ( look at Dan's pp request 3 meetings ago ) while Red Hat employees entirely bypass that and other ( privileged ) processes that community members have to go through. - It elevates it's own "product(s)" above community's work either under the so called "defaults" ( or as we are heading now "3 products" ) or various strategically placed "recommendations" here and there putting competing community maintained products at disadvantage. - It creates ( high ranking ) positions ( suddenly ) in communities, then recruits individuals outside the community and places them in those positions and in those communities ( people can just look through the internet archive's for advertised Fedora positions both for the title they give these individuals as well as the statement you will be working as as opposed to working with ). etc... So as you can see it already is behaving as I think it behaves and quite frankly this is an disgusting and unjust corporate behavior towards the community based on mistrust and misuse and sends mixed signals inside and outside of our community and labels our work as some kind of RH experiment and test bed. All of the issues I have mentioned here before can be dealt with internally by Red Hat. - It has to take a leap of faith and just let go and place trust in the community since it's highly unlikely that it will venture to far away from Red Hat interest at least I would be very surprised if it did. - If it thinks that our processes are to complex for an new employee to walk through to gain the necessary access to be able to perform it's work, it needs to work with us improving those processes and workflows so that *everybody* Red Hat employees and community members alike will gain from it as opposed to be bypassing it altogether for it's employee while the community drowns in bureaucracy. - It will need to understand that forcing everything under a single product ( default ) or three products as well as single audience ( or three different audience ) hinders growth in sub communities ( due to them not being equally presented ) as well as fair competition thus innovation between competing products applications or applications stack ( be it through better written code/compatibility/features/maintenance you know those little things that competing products implement or achieve over each other ) . - It needs to understand that there is no need to invent ( high ranking ) position and try to elevate new employees to those positions within sub community since it will come naturally on it's own by the share time that employees has to work and dedicate to the sub community surrounding the component or group of components. ( An community member only has around 2 - 4 hours max each day to dedicate to the project unless he's unemployed or is being paid to work in it ). So fourth and so on, Red Hat has pretty smart managers and team leaders within their ranks which I'm pretty sure will straight these issues out and deal with the community on equal ground and in harmony which benefits us all. JBG -- 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: sysctl behavior for docker-io
On Sun, Oct 06, 2013 at 07:25:50PM -0400, Matthew Miller wrote: > On Sun, Oct 06, 2013 at 11:32:13PM +0200, Lennart Poettering wrote: > > Or in other words: I don't think it makes much sense to turn this on > > only at runtime inside the service file as matthew suggests, as it hides > > the fact that the setting is made, makes it hard for admins to discover > > and override it, and creates the assumption that the package would turn > > off the setting safely again after the daemon exited, but which it > > doesn't and can't since it doesn't know if anything else still requires > > it. > > Hope that makes some sense, > > It does make some sense; overall I don't think there's a really good answer > here. In trying to figure out what's the most sensible given that, I looked > at what libvirt does, which is turn it on globally in exactly the hidden way > you suggest, and makes no attempt to restore it. I'm not really excited > about that, but apparently that's been the case for a while. Yeah, what libvirt does is really not very nice. If you want to use a routed networking setup though, I don't know of any better options for making this work. We really only wanted to enable forwarding from virbr0, to the LAN, but you can't toggle this per NIC afaick - you have to turn on the global ip_forwarding sysctl. Libvirt just turns it on when first creating its NAT'd device, which for most installs will be at boot time when libvirtd starts. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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 1010057] `perldoc perldoc`: No documentation found for "perldoc".
https://bugzilla.redhat.com/show_bug.cgi?id=1010057 --- Comment #7 from Fedora Update System --- perl-Pod-Perldoc-3.20-7.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Pod-Perldoc-3.20-7.fc20 -- 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=zfc2L8eeG0&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
Re: Red Hat and Fedora Working Groups
- Original Message - > On 10/05/2013 07:08 AM, Mathieu Bridon wrote: > > > > So every time you say that, I can't help thinking you're just jealous > > they took someone « outside the community » instead of you. > > > > It might not be what you're thinking, but it's really how you sound. > > > > Maybe those « individuals » are just more competent? Or you know, > > maybe Red Hat prefers hiring people who don't spend their time > > vomiting their hatred on mailing-lists? > > You are making the assumption that Red Hat has not already offered me a > job as well as the fact that I would associate my name to a company when > behaves like this. I'd say most of Fedora (and even most of Red Hatters) would quit immediately in case the company starts behave like you think it behaves. And I'm saying it as a guy who signed mortgage week ago. And that means I'd still like to see you join us and work on Fedora full time ;-). R. > Good for you... > > JBG > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
