Re: boot.fedoraproject.org (BFO)

On Fri, Jan 24, 2014 at 01:23:13AM +0100, Kevin Kofler wrote: > Peter Lemenkov wrote: > > IMHO you're absolutely wrong. Fortunately it seems that not so much > > people agree with you since I see a lot of activily on a given > > third-party proprietary web service (compared with a dead silence at >

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

- Original Message - > On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell wrote: > > > > As a side note, it also needs to be discussed how such a key feature of > > > the bluetooth stack could go unnoticed through QA, and how to avoid this > > > from happening again. > > > > Indeed. I

Re: Drawing lessons from fatal SELinux bug #1054350

On 01/24/2014 07:35 AM, Rahul Sundaram wrote: Hi On Thu, Jan 23, 2014 at 11:49 PM, Sérgio Basto wrote: yeah , so revoke an update could be a better idea. How would that work? We don't control the mirrors. Fedora controls advertising mirrors (mirrorlists) through mirrormanager. I.e. mir

Re: Drawing lessons from fatal SELinux bug #1054350

On Fri, 2014-01-24 at 01:35 -0500, Rahul Sundaram wrote: > Hi > > > On Thu, Jan 23, 2014 at 11:49 PM, Sérgio Basto wrote: > yeah , so revoke an update could be a better idea. > > > How would that work? We don't control the mirrors. Mirrors can choose > to sync anytime they want to and

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On Fri, 2014-01-24 at 13:50 +0800, Christopher Meng wrote: > Maybe we can learn some metrics from other distros as well. See how > they handle such hot potatos when meeting zombie packagers. I tend to assume Debian's pretty good at this stuff, but aside from them, I strongly doubt the others are a

Re: Drawing lessons from fatal SELinux bug #1054350

Hi On Thu, Jan 23, 2014 at 11:49 PM, Sérgio Basto wrote: > yeah , so revoke an update could be a better idea. > How would that work? We don't control the mirrors. Mirrors can choose to sync anytime they want to and retain packages we have removed. Rahul -- devel mailing list devel@lists.fed

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

Maybe we can learn some metrics from other distros as well. See how they handle such hot potatos when meeting zombie packagers. But, never deem that 5k components is the best number, comparing to other Linux, we are far away behind. They can be used still at the moment, why do we burden ourselves

VTK 6.1.0 in rawhide

I'm hoping to build VTK 6.1.0 tomorrow for rawhide. This will likely require rebuilds of the following, which I will do: InsightToolkit-4.4.2-1.fc20.src.rpm gammaray-1.3.1-3.fc20.src.rpm gammaray-1.3.2-1.fc20.src.rpm mrpt-1.0.2-1.fc20.src.rpm pcl-1.7.0-4.fc20.src.rpm -- Orion Poplawski Technica

Re: Security update process without CVEs

On Thu, 2014-01-23 at 22:53 -0600, Dennis Gilmore wrote: > El Thu, 23 Jan 2014 14:51:51 -0800 > Adam Williamson escribió: > > On Tue, 2014-01-21 at 14:32 -0700, Kevin Fenzi wrote: > > > On Tue, 21 Jan 2014 16:26:19 -0500 > > > Dan Scott wrote: > > > > > > > Hi: > > > > > > > > A few hours ago I

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

Hi On Thu, Jan 23, 2014 at 7:08 PM, Adam Williamson wrote: > On Fri, 2014-01-24 at 01:00 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > Even a simple list of packages ordered by the time from last > > non-mass-rebuild release multiplied by the number of currently open > > bugs would be quite us

Re: Security update process without CVEs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Thu, 23 Jan 2014 14:51:51 -0800 Adam Williamson escribió: > On Tue, 2014-01-21 at 14:32 -0700, Kevin Fenzi wrote: > > On Tue, 21 Jan 2014 16:26:19 -0500 > > Dan Scott wrote: > > > > > Hi: > > > > > > A few hours ago I submitted requests to push

Re: Drawing lessons from fatal SELinux bug #1054350

On Qui, 2014-01-23 at 20:20 -0800, Adam Williamson wrote: > On Fri, 2014-01-24 at 04:18 +, Sérgio Basto wrote: > > > > * The Update Policies must be repealed. This regression has shown us > > > that > > > not only they totally failed at preventing it, but they are actively > > > contributin

Re: Drawing lessons from fatal SELinux bug #1054350

On Fri, 2014-01-24 at 04:18 +, Sérgio Basto wrote: > > * The Update Policies must be repealed. This regression has shown us > > that > > not only they totally failed at preventing it, but they are actively > > contributing to exposing MORE users to broken updates by delaying > > regression

Re: Drawing lessons from fatal SELinux bug #1054350

On Sex, 2014-01-24 at 00:55 +0100, Kevin Kofler wrote: > So, what needs to happen: > * SELinux must be disabled (or preferably, not installed in the first > place, > to avoid wasting space for nothing) by default! Just consider the > benefits > (none!) vs. the risks (what you are seeing now: bric

Re: Fedora.next in 2014 -- Big Picture and Themes

On Fri, 2014-01-24 at 00:12 +0100, Lars Seipel wrote: > On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote: > > Also possibly correct. However, that doesn't preclude the repos as we > > know them today from still existing, with still the same quality. > > Server, desktop or embedded board

Re: Drawing lessons from fatal SELinux bug #1054350

On Fri, 2014-01-24 at 00:55 +0100, Kevin Kofler wrote: > Last time an issue like that happened (the D-Bus regression that broke > updates), That was my fault. Something which left an impact on me, you can be sure. Like SELinux, DBus impacts everything nearly everything in early userspace. In

Re: Security update process without CVEs

On Fri, Jan 24, 2014 at 11:15 AM, Adam Williamson wrote: > It's not 7 days at least. It's 0 days at least. It's 7 days at least *if > you get no positive karma*. Yes, but nearly 90% of these security updates receive no karma feedback still, they lack tests. -- devel mailing list devel@lists.fed

Re: Security update process without CVEs

On Fri, 2014-01-24 at 11:11 +0800, Christopher Meng wrote: > Which poor sod will be the victim in 7 days at least before pushing to > stable? ;) It's not 7 days at least. It's 0 days at least. It's 7 days at least *if you get no positive karma*. -- Adam Williamson Fedora QA Community Monkey IRC:

Re: boot.fedoraproject.org (BFO)

Once upon a time, Kevin Kofler said: > This shows that people have not learned ANYTHING from the ButtKeeper fiasco. > :-( I think there's a big difference between that and Github. AFAIK Github isn't trying to claim ownership of all data and metadata related to hosted projects, or restrict who c

Re: Security update process without CVEs

Which poor sod will be the victim in 7 days at least before pushing to stable? ;) Then comes another question, does security updates need to be treat as special? It's just an original update with a tag "security alert", but users still need to wait 7 days unless they enable updates-testing. -- de

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, Jan 23, 2014 at 9:41 PM, Adam Williamson wrote: > On Thu, 2014-01-23 at 21:35 -0500, Orcan Ogetbil wrote: >> >> Right. But is it possible to ship a bluez4 package and rebuild the >> dependencies against that after the release? > > How does that differ, in practice? Potentially, - No epoch

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, 2014-01-23 at 21:35 -0500, Orcan Ogetbil wrote: > On Thu, Jan 23, 2014 at 7:33 PM, Kevin Kofler wrote: > > David Sommerseth wrote: > >> So, I wonder if it can be considered to enable a "downgrade path" for > >> bluez and depending packages, as described in the "Contingency Plan": > >>

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, Jan 23, 2014 at 7:33 PM, Kevin Kofler wrote: > David Sommerseth wrote: >> So, I wonder if it can be considered to enable a "downgrade path" for >> bluez and depending packages, as described in the "Contingency Plan": >> > > Officially downgrad

Re: What to do about packaging beta, or rc as alternate installable

On Thu, 2014-01-23 at 19:19 -0700, Pete Travis wrote: > Is there something inherent to COPRs that solves the problem of > duplicate paths, ie /usr/bin/mercurial from two different sources? > > If I missed something, a link with an appropriate measure of mocking > would be welcome. Not AFAIK. If

Re: What to do about packaging beta, or rc as alternate installable

On Jan 23, 2014 1:12 PM, "Stephen Gallagher" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/23/2014 01:43 PM, Kevin Kofler wrote: > > Christopher Meng wrote: > >> But you can do this on copr IMO. Also update-testing is not just > >> a place for updates to have a break, you c

Re: Fedora.next in 2014 -- Big Picture and Themes

Josh Boyer (jwbo...@fedoraproject.org) said: > I wasn't being dismissive. I have seen no plans to alter the core of > how Fedora, at a package level, is built. In fact, if I did see a > proposal that said "we're not going to ship repositories or RPMs" I'd > be pretty damned upset, and I wouldn't

Re: Drawing lessons from fatal SELinux bug #1054350

On Fri, Jan 24, 2014 at 10:37 AM, Kevin Kofler wrote: > Eric Sandeen wrote: > > If the solution to every serious bug that slips through the cracks of a > > release is to disable the package, over time we may not have much left in > > Fedora. > > But SELinux is the one package (OK, one of the few,

Re: Drawing lessons from fatal SELinux bug #1054350

On Fri, 2014-01-24 at 02:34 +0100, Kevin Kofler wrote: > though ideally we shouldn't have > servers trying to listen to non-local connections by default in the first > place! Doing so is specifically forbidden by policy, and the few packages that do it had to seek a special exemption from FESCo

Re: Drawing lessons from fatal SELinux bug #1054350

Eric Sandeen wrote: > Sure, removing firewalls & selinux would be a serious enhancement > of functionality. > > For malware botnets & spam hosts, especially... That would mean that all the distributions that do not enable SELinux (nor AppArmor) by default are all owned by botnets, not to mention

Re: boot.fedoraproject.org (BFO)

On 01/24/2014 01:05 AM, Rahul Sundaram wrote: Hi On Thu, Jan 23, 2014 at 7:34 PM, Adam Williamson wrote: I don't like github being non-free, particularly, but the practical consequences of that are fairly minor. Tickets and history of those tickets can be important You can expor

Re: Drawing lessons from fatal SELinux bug #1054350

On 1/23/14, 6:37 PM, Kevin Kofler wrote: > Eric Sandeen wrote: >> If the solution to every serious bug that slips through the cracks of a >> release is to disable the package, over time we may not have much left in >> Fedora. > > But SELinux is the one package (OK, one of the few, along with, e.g.

Re: boot.fedoraproject.org (BFO)

On Thu, 2014-01-23 at 20:05 -0500, Rahul Sundaram wrote: > Hi > > > On Thu, Jan 23, 2014 at 7:34 PM, Adam Williamson wrote: > > > I don't like github being non-free, particularly, but the > practical > consequences of that are fairly minor. > > > Ticket

Re: boot.fedoraproject.org (BFO)

Hi On Thu, Jan 23, 2014 at 7:34 PM, Adam Williamson wrote: > > > I don't like github being non-free, particularly, but the practical > consequences of that are fairly minor. > Tickets and history of those tickets can be important Rahul -- devel mailing list devel@lists.fedoraproject.org https

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, 2014-01-23 at 16:59 -0600, Dan Williams wrote: > Out of curiosity, what do people use Blueman for? It includes an applet that could be used instead of the one that ships with GNOME that is now tied to Bluez5. I was merely putting it forth as what one could use for an applet if one were t

Re: boot.fedoraproject.org (BFO)

On 23 January 2014 17:28, Kevin Kofler wrote: > Adam Williamson wrote:request process down people's throats). > > > has anyone yet publicly noted the irony of someone building a wildly > > successful proprietary SCM platform on top of a project that was written > > to rescue the kernel from a pro

Re: Drawing lessons from fatal SELinux bug #1054350

Eric Sandeen wrote: > If the solution to every serious bug that slips through the cracks of a > release is to disable the package, over time we may not have much left in > Fedora. But SELinux is the one package (OK, one of the few, along with, e.g., firewall stuff) whose removal would actually IN

Re: boot.fedoraproject.org (BFO)

On Thu, 2014-01-23 at 16:34 -0800, Adam Williamson wrote: > It's hardly a bitbucket > situation. Damnit, I mean bitkeeper. I have those two wires crossed somewhere in my brain. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net ht

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

David Sommerseth wrote: > So, I wonder if it can be considered to enable a "downgrade path" for > bluez and depending packages, as described in the "Contingency Plan": > Officially downgrading BlueZ from 5 to 4 in a shipped release is totally imprac

Re: boot.fedoraproject.org (BFO)

On Fri, 2014-01-24 at 01:23 +0100, Kevin Kofler wrote: > Fedora MUST NOT be at the whim of third-party code hosting services, > especially proprietary ones. I don't see how the code being on github means you're at anyone's 'whim'. git is a self-contained, distributed scm. If github turns evil, t

Re: boot.fedoraproject.org (BFO)

On Fri, 24 Jan 2014 01:23:13 +0100 Kevin Kofler wrote: > That's why we need enforcement. There should be a statement from a > competent committee (Board, FESCo, whomever) that effective NOW, > stuff can ONLY be uploaded to production (and staging too, probably) > infrastructure if it is either: >

Re: boot.fedoraproject.org (BFO)

Adam Williamson wrote: > And you can, of course, just mail patches to mailing lists. That's what > git was designed for in the first place, and it appears to work > perfectly well for kernel and anaconda devs... Or simply attach them to an issue in the issue tracker, which works with practically

Re: boot.fedoraproject.org (BFO)

Peter Lemenkov wrote: > IMHO you're absolutely wrong. Fortunately it seems that not so much > people agree with you since I see a lot of activily on a given > third-party proprietary web service (compared with a dead silence at > fedorahosted). So actually people already voted, and they voted > aga

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On Fri, 2014-01-24 at 01:00 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jan 23, 2014 at 04:53:47PM -0700, Kevin Fenzi wrote: > > On Thu, 23 Jan 2014 15:26:24 -0800 > > Adam Williamson wrote: > > I think ideally any process around this should have at least two parts: > > > > a) an automat

Re: Drawing lessons from fatal SELinux bug #1054350

On 1/23/14, 5:55 PM, Kevin Kofler wrote: > * We are enabling SELinux enabled (enforcing) by default, a tool designed to > prevent anything it does not like from happening. (Reread this carefully: > The ONLY thing that tool is designed to do at all is PREVENT things. It does > not have a SINGLE f

Re: Drawing lessons from fatal SELinux bug #1054350

On Fri, 2014-01-24 at 00:55 +0100, Kevin Kofler wrote: > Hi, > "catastrophic Fedora 20 regression" > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 > "rpm scriptlets are exiting with status 127" > "EVERYONE" > "IMPOSSIBLE" to fix this using GUI tools installed by default. The > "some stupid re

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On Thu, Jan 23, 2014 at 04:53:47PM -0700, Kevin Fenzi wrote: > On Thu, 23 Jan 2014 15:26:24 -0800 > Adam Williamson wrote: > I think ideally any process around this should have at least two parts: > > a) an automated/scriptable part. > > In this part the script uses cold hard facts to look for

Drawing lessons from fatal SELinux bug #1054350

Hi, it is time to analyze the fallout from the following catastrophic Fedora 20 regression: https://bugzilla.redhat.com/show_bug.cgi?id=1054350 "rpm scriptlets are exiting with status 127" The impact: * EVERYONE with Fedora 20 installed with SELinux enabled and in enforcing mode, and who update

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On Thu, 23 Jan 2014 15:26:24 -0800 Adam Williamson wrote: > Well, let's say it's certainly not 'low-hanging fruit' :) > > I'm not saying I have all the answers, just suggesting a possibly more > productive course. At least now we have people co-operatively > discussing the possibilities and pote

Re: What to do about packaging beta, or rc as alternate installable

On Jan 24, 2014 7:14 AM, "Adam Williamson" wrote: > In other words: Christopher, if you're currently doing this, please move > the packages to a COPR or other venue more appropriate for this purpose, > and stop doing it. No absolutely not. I don't have any thing *unstable*. Something unstable ar

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On Thu, Jan 23, 2014 at 04:19:11PM -0700, Kevin Fenzi wrote: > I mean, I'm a maintainer for the Fedora apg package. > Last upstream release was 2003. I very rarely touch it. > Yet, from time to time I still use it here, I suspect, but do not know > that others install and use it. Ooh. I do! Kee

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On Thu, 2014-01-23 at 16:19 -0700, Kevin Fenzi wrote: > On Thu, 23 Jan 2014 15:08:13 -0800 > Adam Williamson wrote: > > ...snip... > > > I don't think that's true at all. Would anyone on either side of the > > debate object to an approach which tried to identify software that was > > truly aband

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On 23/01/14 22:59, Dan Williams wrote: Out of curiosity, what do people use Blueman for? Not me personally, but browsing for files on a remote bluetooth device [1]. With BlueZ 5, one can only push files from a device to a fedora box (or from a fedora box to a device) [2]. [1] https://bugzi

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On Fri, 2014-01-24 at 00:15 +0100, Reindl Harald wrote: > > I'm sure there's at least a certain amount of low-hanging fruit that > > no-one would really mind getting rid of > > but how make the decisions and who do the work of investigation? Sure, that's something that would have to get figured

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 23:50 +0100, drago01 wrote: > On Thu, Jan 23, 2014 at 11:38 PM, Adam Williamson wrote: > > On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote: > > > >> > No, I don't disagree with you there. But the repos don't exist in a > >> > vacuum. Right now they are our way of shipping so

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On Thu, 23 Jan 2014 15:08:13 -0800 Adam Williamson wrote: ...snip... > I don't think that's true at all. Would anyone on either side of the > debate object to an approach which tried to identify software that was > truly abandoned either up- or down-stream - not just 'software that no > longer r

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell wrote: > > As a side note, it also needs to be discussed how such a key feature of > > the bluetooth stack could go unnoticed through QA, and how to avoid this > > from happening again. > > Indeed. I wondered the same myself. I'm somewhat chee

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

Am 24.01.2014 00:08, schrieb Adam Williamson: > On Thu, 2014-01-23 at 16:55 +0100, Reindl Harald wrote: >> Am 23.01.2014 16:49, schrieb Jóhann B. Guðmundsson: >>> >>> On 01/23/2014 01:48 PM, Matthew Miller wrote: So, one possibility would be to move less-maintained packages to a separate >>>

Re: What to do about packaging beta, or rc as alternate installable

On Thu, 2014-01-23 at 15:11 -0800, Adam Williamson wrote: > On Thu, 2014-01-23 at 19:43 +0100, Kevin Kofler wrote: > > Christopher Meng wrote: > > > But you can do this on copr IMO. Also update-testing is not just a place > > > for updates to have a break, you can let it satisfy the needs of testi

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 02:16:23PM -0800, Adam Williamson wrote: > Read all the above sequentially. My point is that although you are > technically correct that no WG has proposed doing away with the repos, > the RPM format, or yum/dnf, their plans - under a reasonable > interpretation of the discu

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote: > Also possibly correct. However, that doesn't preclude the repos as we > know them today from still existing, with still the same quality. Server, desktop or embedded board, in today's Fedora it's all the same, just with a different pac

Re: What to do about packaging beta, or rc as alternate installable

On Thu, 2014-01-23 at 19:43 +0100, Kevin Kofler wrote: > Christopher Meng wrote: > > But you can do this on copr IMO. Also update-testing is not just a place > > for updates to have a break, you can let it satisfy the needs of testing > > for unstable. > > Well, that's kinda abusing updates-testi

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On Thu, 2014-01-23 at 16:55 +0100, Reindl Harald wrote: > Am 23.01.2014 16:49, schrieb Jóhann B. Guðmundsson: > > > > On 01/23/2014 01:48 PM, Matthew Miller wrote: > >> So, one possibility would be to move less-maintained packages to a separate > >> repository tree still included as Fedora and ena

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, 2014-01-23 at 16:58 -0500, Brian J. Murrell wrote: > On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: > > > > Nope, several packages depends on the bluez-5.13-1 package. > > Indeed. However I could probably live without gnome-bluetooth if > blueman were still available. > > pu

Re: boot.fedoraproject.org (BFO)

On Wed, 2014-01-22 at 17:02 -0700, Kevin Fenzi wrote: > On Thu, 23 Jan 2014 00:41:52 +0400 > Peter Lemenkov wrote: > > > 2014/1/23 Kevin Fenzi : > > > > > Can you please file a infrastructure ticket on this and I will get > > > it updated. > > > > Don't know what others think, but I personally

Re: Fedora.next in 2014 -- Big Picture and Themes

Am 23.01.2014 23:49, schrieb drago01: > On Thu, Jan 23, 2014 at 11:46 PM, Reindl Harald > wrote: >> >> Am 23.01.2014 23:37, schrieb drago01: >>> On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson >>> wrote: No, I don't disagree with you there. But the repos don't exist in a vacuum. Ri

Re: Security update process without CVEs

On Tue, 2014-01-21 at 14:32 -0700, Kevin Fenzi wrote: > On Tue, 21 Jan 2014 16:26:19 -0500 > Dan Scott wrote: > > > Hi: > > > > A few hours ago I submitted requests to push perl-MARC-XML directly to > > stable (by filling out the "fedpkg update" request with type=security > > and request=stable)

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 11:38 PM, Adam Williamson wrote: > On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote: > >> > No, I don't disagree with you there. But the repos don't exist in a >> > vacuum. Right now they are our way of shipping software in Fedora: our >> > *only* way. If you want to instal

Re: .spec file Source0 magic for github release source tarballs?

On Tue, 2014-01-21 at 11:09 -0600, Richard Shaw wrote: > On Tue, Jan 21, 2014 at 11:06 AM, Miroslav Suchý > wrote: > On 01/21/2014 06:01 PM, Kaleb KEITHLEY wrote: > > > > Take, for example, > https://github.com/nfs-ganesha/nfs-ganesha/releases, where > there

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 11:46 PM, Reindl Harald wrote: > > Am 23.01.2014 23:37, schrieb drago01: >> On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson >> wrote: >>> No, I don't disagree with you there. But the repos don't exist in a >>> vacuum. Right now they are our way of shipping software in F

Re: Fedora.next in 2014 -- Big Picture and Themes

Am 23.01.2014 23:37, schrieb drago01: > On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson wrote: >> No, I don't disagree with you there. But the repos don't exist in a >> vacuum. Right now they are our way of shipping software in Fedora: our >> *only* way. If you want to install the Fedora-y vers

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote: > > No, I don't disagree with you there. But the repos don't exist in a > > vacuum. Right now they are our way of shipping software in Fedora: our > > *only* way. If you want to install the Fedora-y version of a particular > > piece of software, yo

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson wrote: > On Thu, 2014-01-23 at 17:26 -0500, Josh Boyer wrote: > >> > Read all the above sequentially. My point is that although you are >> > technically correct that no WG has proposed doing away with the repos, >> > the RPM format, or yum/dnf, the

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 17:26 -0500, Josh Boyer wrote: > > Read all the above sequentially. My point is that although you are > > technically correct that no WG has proposed doing away with the repos, > > the RPM format, or yum/dnf, their plans - under a reasonable > > interpretation of the discussi

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 5:16 PM, Adam Williamson wrote: > quoting simplified: >>> is Tom Hughes, >> is me, > is Josh. Restored > part of Tom's original context. > >>> > The actual spins (or whatever you want to call them) aren't something >>> > that bother me at all, as they are to my mind largely

Re: Fedora.next in 2014 -- Big Picture and Themes

quoting simplified: >>> is Tom Hughes, >> is me, > is Josh. Restored part of Tom's original context. >> > The actual spins (or whatever you want to call them) aren't something >> > that bother me at all, as they are to my mind largely irrelevant for >> > anybody other than a new user. When I bri

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Jan 23, 2014, at 2:56 PM, "Brian J. Murrell" wrote: > On Thu, 2014-01-23 at 19:53 +0100, David Sommerseth wrote: > >> As a side note, it also needs to be discussed how such a key feature of >> the bluetooth stack could go unnoticed through QA, and how to avoid this >> from happening again.

Re: Fedora.next in 2014 -- Big Picture and Themes

On 23 January 2014 14:14, Josh Boyer wrote: > On Thu, Jan 23, 2014 at 3:53 PM, Stephen John Smoogen > wrote: > > > My view of the matter was pretty much the same as Tom's and I was at > FLOCK. > > The language at the sessions I attended was not one of "We would like to > do > > this" but that it

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 4:57 PM, Adam Williamson wrote: > On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote: >> On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson wrote: >> > On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: >> > >> >> > To be honest my concerns are more with my user hat on th

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 01:57:38PM -0800, Adam Williamson wrote: > If these plans go ahead, we will have multiple official/blessed methods > for deploying software on Fedora, potentially with different policies > about what software they can include and how that software should be > arranged, how d

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 23 Jan 2014 13:57:38 -0800 Adam Williamson wrote: > The repos will still exist, but things will be different. At present, > the Fedora repos are the single unified official Fedora method for > deploying software on Fedora products. Any other method you can use to > deploy software is not

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: > > Nope, several packages depends on the bluez-5.13-1 package. Indeed. However I could probably live without gnome-bluetooth if blueman were still available. pulseaudio-module-bluetooth though. Would it work with Bluez4? Would it nee

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote: > On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson wrote: > > On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: > > > >> > To be honest my concerns are more with my user hat on than my contributor > >> > hat - that we will lose the gold stand

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, 2014-01-23 at 19:53 +0100, David Sommerseth wrote: > Hi all, Hi, > This might be a viewed as a fire torch, but there is, IMO, a major > regression in BlueZ 5 which is shipped in Fedora 20. I agree. But everyone probably already knows that. > It doesn't support > HSP/HFP headset profil

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson wrote: > On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: > >> > To be honest my concerns are more with my user hat on than my contributor >> > hat - that we will lose the gold standard unified packaging standards and >> > single source and mech

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: > > To be honest my concerns are more with my user hat on than my contributor > > hat - that we will lose the gold standard unified packaging standards and > > single source and mechanism for installing packages. > > I haven't seen anything fro

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote: > wikipedia page. Further: kororaproject.org, fedorautils-installer and > similar project show that there are people that want to make Fedora > better. But they do their work outside of Fedora and RPM Fusion; > fixing the issues directly

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote: > Hi! > > On 03.01.2014 19:14, Matthew Miller wrote: > > […] So those are my things. What do you think about them? What > > else should be included? What different directions should we > > consider? How will we make Fedora more awesome th

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, 23 Jan 2014 19:03:02 +0100 Thorsten Leemhuis wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi! > > On 03.01.2014 19:14, Matthew Miller wrote: > > […] So those are my things. What do you think about them? What > > else should be included? What different directions should

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

Hi, On Thu, Jan 23, 2014 at 11:06:16AM -0700, Chris Murphy wrote: > > What I wanted to point out is that forced removal > > of packages _is not_ going to guarantee more packager's attention to > > the rest of the distribution. > > Is there a reading comprehension problem in this thread? I don't r

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 7:03 PM, Thorsten Leemhuis wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi! > > On 03.01.2014 19:14, Matthew Miller wrote: >> […] So those are my things. What do you think about them? What >> else should be included? What different directions should we >>

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 3:53 PM, Stephen John Smoogen wrote: > > > > On 23 January 2014 11:48, Josh Boyer wrote: >> >> On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes wrote: >> >> > Personally I think a lot of it has to do with the way the whole thing >> > seemed >> > to be a fait accompli such that

Re: Fedora.next in 2014 -- Big Picture and Themes

On 23 January 2014 11:48, Josh Boyer wrote: > On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes wrote: > > > Personally I think a lot of it has to do with the way the whole thing > seemed > > to be a fait accompli such that there seemed to be little point doing > > anything other than sitting back and

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote: > On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: > > On 23/01/14 19:58, Frank Murphy wrote: > > > On Thu, 23 Jan 2014 19:53:19 +0100 > > > David Sommerseth wrote: > > > > > >> > > >> Hi all, > > >> > > >> This might be a viewed as

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote: > On 23/01/14 19:58, Frank Murphy wrote: > > On Thu, 23 Jan 2014 19:53:19 +0100 > > David Sommerseth wrote: > > > >> > >> Hi all, > >> > >> This might be a viewed as a fire torch, but there is, IMO, a major > >> regression in BlueZ 5 whic

Re: What to do about packaging beta, or rc as alternate installable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 01:43 PM, Kevin Kofler wrote: > Christopher Meng wrote: >> But you can do this on copr IMO. Also update-testing is not just >> a place for updates to have a break, you can let it satisfy the >> needs of testing for unstable. > > Well, t

Re: Fedora.next in 2014 -- Big Picture and Themes

On Thu, Jan 23, 2014 at 07:03:02PM +0100, Thorsten Leemhuis wrote: > Okay, I'll bite (after thinking whether writing this mail is worth it): Thanks. I hope that I can make you feel that it was. > The main reason for that: Fedora.next is a huge effort that seems to > make everything even more comp

[perl-DateTime-Set] Created tag perl-DateTime-Set-0.33-3.el7

The lightweight tag 'perl-DateTime-Set-0.33-3.el7' was created pointing to: 5a29747... Bootstrap of epel7 done -- 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/p

Re: SELinux RPM scriplet issue annoucement

On Tue, 2014-01-21 at 09:54 -0500, Matthias Clasen wrote: > On Mon, 2014-01-20 at 23:18 -0800, Adam Williamson wrote: > > On Tue, 2014-01-21 at 01:01 -0600, Ian Pilcher wrote: > > > On 01/20/2014 11:48 AM, Adam Williamson wrote: > > > > The bug currently under discussion was caused by a change that

[perl-HTML-TableExtract] Fix requires.

Summary of changes: f5efb4b... Fix requires. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailm

[Bug 1056804] (possibly) branch for EPEL 7

https://bugzilla.redhat.com/show_bug.cgi?id=1056804 Bill Nottingham changed: What|Removed |Added Status|NEW |CLOSED Resolution|---

  1   2   >