Re: No more deltarpms by default

On Fri, Oct 17, 2014 at 9:58 AM, Tom Rivers wrote: > My point was to say Linux users are usually more tech savvy than XBox and > Playstation users. If they say they have a high speed connection and they > don't and that decision ends up costing them more money in ISP costs, then > that's on them

Self Introduction: Piotr Popieluch

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, My name is Piotr Popieluch and live in the Hague in the Netherlands. I work as a Unix sysadmin with focus on monitoring. I manage rhel boxes professionally and use Fedora on my laptop. Because of this I want to give back and want to become a F

[Test-Announce] Fedora 21 Beta Test Compose 4 (TC4) Available Now!

As per the Fedora 21 schedule [1], Fedora 21 Beta Test Compose 4 (TC4) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6010#comment:7 . Please see the following pages for download links (including delta ISOs) and testing

5tFTW: Fedora Council, L10N Zanata, FUDCon LATAM, Taskotron, and Retrace improvements (2014-10-17)

Reposted from . Fedora is a big project, and it’s hard to keep up with everything that goes on. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to e

[Test-Announce] PSA: Don't install kernels with grubby 8.35-6.fc21 - they won't boot

Hi, folks. I've just noticed that grubby 8.35-6.fc21 made it to the updates-testing repository. That build has a rather bad bug - when it writes grub entries it will likely leave out the 'initrd16' (or just 'initrd', depending how old your system is) line, which will probably mean the kernel won't

Re: No more deltarpms by default

On Fri, Oct 17, 2014 at 2:44 PM, Tom Rivers wrote: > > I suppose I'm having trouble understanding that when you started this > thread with:ble by default for many users. dnf should enable this > configuration by default as well" Yes, that was true when I posted it. As a result of this discussi

Re: No more deltarpms by default

On 10/17/2014 14:24, Rahul Sundaram wrote: Deltarpms is again enabled by default in Dnf a while back if you read the bug report. Everything else has been an tangent, yes. I suppose I'm having trouble understanding that when you started this thread with: On 10/6/2014 04:41, Rahul Sundaram w

civil discussion on fedora lists

On Fri, Oct 17, 2014 at 06:24:03PM +0200, Ralf Corsepius wrote: > >Everyone: please remember the code of conduct here, and advance the > >conversation in a productive way or take it elsewhere. Thank you. > Well, then please explain, how you expect people to express > fundamental disagreement with s

Re: No more deltarpms by default

Hi On Fri, Oct 17, 2014 at 2:17 PM, Tom Rivers wrote: > > I would really like to know how you can equate that with my original > point: "Hey, maybe instead of throwing Presto under the bus.." We aren't though. Deltarpms is again enabled by default in Dnf a while back if you read the bug repo

Re: No more deltarpms by default

On 10/17/2014 13:19, Rahul Sundaram wrote: For the last time, my point is that: "smart" and "stupid" is not determined by whether a user understands bandwidth/processor considerations. I completely understand that not comprehending all of the complexities of bandwidth/processor consideration

Re: No more deltarpms by default

Am 17.10.2014 um 19:45 schrieb drago01: 1) deltarpms -> low bandwidth use but takes a while to apply the updates 2) no deltarpms -> high bandwidth use but faster updates application. So now people suggest the user (or the distro) has to either choose 1) or 2) ... What I am suggesting is adding

Re: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)

On Fri, Oct 17, 2014 at 5:59 PM, Richard W.M. Jones wrote: > On Thu, Oct 16, 2014 at 04:47:29PM +0200, Mathieu Bridon wrote: >> >> [cduce] >> >>cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = >> >> 0:ebd368022fd2bc7b305a42902efa4c90 >> >> This fails to rebuild: >> https://koji.fedorapro

Re: No more deltarpms by default

On Fri, Oct 17, 2014 at 6:50 PM, Reindl Harald wrote: > > Am 17.10.2014 um 17:07 schrieb drago01: > >> On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius >> wrote: >>> >>> On 10/17/2014 04:24 PM, Tom Rivers wrote: On 10/17/2014 10:05, drago01 wrote: > > > Because it makes

review swap : libmozjpeg

Hi https://bugzilla.redhat.com/show_bug.cgi?id=1154163 Let me know if anyone is interested. Thanks! Rahul -- 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: No more deltarpms by default

Hi On Fri, Oct 17, 2014 at 1:03 PM, Tom Rivers wrote: > If you deconstruct the sentence you quoted above, it boils down to the > subject "users" and the predicate "aren't". Therefore I said quite > specifically that users ARE NOT "too stupid to understand > bandwidth/processor considerations."

Re: LLVM 3.5 rebase

2014-10-17 16:00 GMT+02:00 Peter Robinson : > On Fri, Oct 17, 2014 at 2:56 PM, Adam Jackson wrote: > > Yep, this again. I'm just as thrilled as you are. 3.5 is necessary for > > proper ppc64le support, as well as some minor radeonsi features in Mesa. > > And massively improved aarch64 support >

Re: No more deltarpms by default

On 10/17/2014 11:29, Rahul Sundaram wrote: On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers wrote: I didn't call them stupid - in fact I suggested just the opposite. Go back and read what I wrote. I did. You said "My point is that users aren't too stupid to understand bandwidth/processor

Re: No more deltarpms by default

On 10/17/2014 12:11, Gerald B. Cox wrote: I think you're setting up a false equivalency here. There is a difference between the requirements of say an XBOX or Playstation user and that of updating a Fedora system. If given the choice, most people will say "Yes, I have a high speed connection.

Re: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)

On Thu, Oct 16, 2014 at 04:47:29PM +0200, Mathieu Bridon wrote: > >> [cduce] > >>cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = > >> 0:ebd368022fd2bc7b305a42902efa4c90 > > This fails to rebuild: > https://koji.fedoraproject.org/koji/taskinfo?taskID=7881630 This was waiting for an upst

Re: No more deltarpms by default

Am 17.10.2014 um 17:07 schrieb drago01: On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius wrote: On 10/17/2014 04:24 PM, Tom Rivers wrote: On 10/17/2014 10:05, drago01 wrote: Because it makes no sense and pushes it to the user. The os (i.e we) should handle that. In that case we should do bo

Re: No more deltarpms by default

On Fri, Oct 17, 2014 at 5:52 PM, Ralf Corsepius wrote: > On 10/17/2014 05:07 PM, drago01 wrote: >> >> On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius >> wrote: >>> >>> On 10/17/2014 04:24 PM, Tom Rivers wrote: On 10/17/2014 10:05, drago01 wrote: > > > Because it makes n

Re: Qt 5 Fedora 21 packages

On 16/10/14 16:27, Kevin Kofler wrote: > Michael Schwendt wrote: >> Some confusion here trying to use Fedora's Qt 5 packages, and it seems >> they cannot be use quickly. > > Depends on the build system you (or the upstream project you're packaging) > use: > * CMake: just works > * qmake: call q

Re: No more deltarpms by default

On 10/17/2014 06:00 PM, Matthew Miller wrote: Everyone: please remember the code of conduct here, and advance the conversation in a productive way or take it elsewhere. Thank you. Well, then please explain, how you expect people to express fundamental disagreement with somebody's rationale, if

Re: No more deltarpms by default

On Fri, Oct 17, 2014 at 7:24 AM, Tom Rivers wrote: > If the proper configuration can be determined automagically, then by all > means just do it. My point is that users aren't too stupid to understand > bandwidth/processor considerations. The configuration of how much > bandwidth/processor time

Re: No more deltarpms by default

On Mon, Oct 6, 2014 at 8:07 AM, Stephen Gallagher wrote: [ . . . ] > > It would be nice to see if we can find ways to improve the performance > of the deltarpm reconstruction instead. Much of the time is spent on > compression/decompression tasks which *should* be massively parallel; we > should

Re: No more deltarpms by default

Everyone: please remember the code of conduct here, and advance the conversation in a productive way or take it elsewhere. Thank you. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of

Re: No more deltarpms by default

On 10/17/2014 05:07 PM, drago01 wrote: On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius wrote: On 10/17/2014 04:24 PM, Tom Rivers wrote: On 10/17/2014 10:05, drago01 wrote: Because it makes no sense and pushes it to the user. The os (i.e we) should handle that. In that case we should do both

Re: Review swap

On Fri, Oct 17, 2014 at 1:30 AM, Tim Lauridsen wrote: > I will take it later today, if nobody beat me to it :) Thank you, Tim. Let me know what I can do for you, whether it be a review or something else. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedora

Re: No more deltarpms by default

Hi On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers wrote: I didn't call them stupid - in fact I suggested just the opposite. Go back > and read what I wrote. > I did. You said "My point is that users aren't too stupid to understand bandwidth/processor considerations". I am just saying even if on

Re: No more deltarpms by default

On 10/17/2014 10:43, Rahul Sundaram wrote: Wile users might be able to handle such questions (I would avoid calling them stupid even otherwise) I didn't call them stupid - in fact I suggested just the opposite. Go back and read what I wrote. , it is contrary to the goals of the installer. T

Re: No more deltarpms by default

On 06.10.2014 16:46, Jaroslav Reznik wrote: > - Original Message - >> >> >> >> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote: >>> On 6 October 2014 09:41, Rahul Sundaram wrote: Hi One of the long standing features that were enabled by default in yum is support for

Re: No more deltarpms by default

On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius wrote: > On 10/17/2014 04:24 PM, Tom Rivers wrote: >> >> On 10/17/2014 10:05, drago01 wrote: >>> >>> Because it makes no sense and pushes it to the user. The os (i.e we) >>> should handle that. In that case we should do both 1) have lower >>> bandwit

[Bug 1154078] perl-Net-CUPS-0.61-18.fc22 FTBFS: The version of the Common Unix Printing System installed on your system is too old for this module to work properly.

https://bugzilla.redhat.com/show_bug.cgi?id=1154078 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED CC|

Re: No more deltarpms by default

On 10/17/2014 04:24 PM, Tom Rivers wrote: On 10/17/2014 10:05, drago01 wrote: Because it makes no sense and pushes it to the user. The os (i.e we) should handle that. In that case we should do both 1) have lower bandwith requirements (i.e use deltas) *and* 2) have fast installation of updates. T

Re: No more deltarpms by default

Hi On Fri, Oct 17, 2014 at 10:24 AM, Tom Rivers wrote: > > If the proper configuration can be determined automagically, then by all > means just do it. My point is that users aren't too stupid to understand > bandwidth/processor considerations. The configuration of how much > bandwidth/process

Re: el6 builds failing

On Fri, 17 Oct 2014 16:17:39 +0200 Jan Chaloupka wrote: > Working now FYI, this is usually due to an update landing in our repos and koji hasn't done a regen on it yet so it's trying to get the old package version. It should sort itself out on the next newrepo. kevin -- > > On 10/17/2014 02

Re: No more deltarpms by default

On 10/17/2014 10:05, drago01 wrote: Because it makes no sense and pushes it to the user. The os (i.e we) should handle that. In that case we should do both 1) have lower bandwith requirements (i.e use deltas) *and* 2) have fast installation of updates. Those two goals are not mutually exclusive

Re: el6 builds failing

Working now On 10/17/2014 02:50 PM, Jan Chaloupka wrote: Hi, an hour ago I was able to build golang-github-mitchellh-mapstructure package for el6: http://koji.fedoraproject.org/koji/packageinfo?packageID=19293 Now it fails (some of my scratch builds): http://koji.fedoraproject.org/koji/taski

Re: No more deltarpms by default

On Fri, Oct 17, 2014 at 2:53 PM, Tom Rivers wrote: > On 10/17/2014 05:09, Reindl Harald wrote: >> >> on a 56kbit modem you don't want to download the full RPMs and on a >> 150Mbit line the download will always be faster than rebuild the RPM > > > Perhaps this has already been suggested, but why no

Re: LLVM 3.5 rebase

On Fri, Oct 17, 2014 at 2:56 PM, Adam Jackson wrote: > Yep, this again. I'm just as thrilled as you are. 3.5 is necessary for > proper ppc64le support, as well as some minor radeonsi features in Mesa. And massively improved aarch64 support > One problem this time around appears to be python-ll

LLVM 3.5 rebase

Yep, this again. I'm just as thrilled as you are. 3.5 is necessary for proper ppc64le support, as well as some minor radeonsi features in Mesa. One problem this time around appears to be python-llvmpy, which appears to have decided that llvm 3.2/3.3 are the only versions it will support: https:

Re: No more deltarpms by default

On 10/17/2014 05:09, Reindl Harald wrote: on a 56kbit modem you don't want to download the full RPMs and on a 150Mbit line the download will always be faster than rebuild the RPM Perhaps this has already been suggested, but why not ask a question during the installation of the OS? For example

el6 builds failing

Hi, an hour ago I was able to build golang-github-mitchellh-mapstructure package for el6: http://koji.fedoraproject.org/koji/packageinfo?packageID=19293 Now it fails (some of my scratch builds): http://koji.fedoraproject.org/koji/taskinfo?taskID=7894679 http://koji.fedoraproject.org/koji/taski

[Base] Base Design WG agenda meeting 17 October 2014 15:00 UTC on #fedora-meeting

Agenda: - Status buildrequires cleanup work (davids & nils!) - 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 |

rawhide report: 20141017 changes

Compose started at Fri Oct 17 05:15:02 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Agda] ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Ag

Re: No more deltarpms by default

Roberto Ragusa robertoragusa.it> writes: > Are compressed rpms completely impossible to diff efficiently by rsync? In a word, yes. They're already compressed, so it's unlikely there would be any matching blocks between old and new rpms for rsync to take advantage of. (You can verify this by tryi

Re: enhancing crypto policies for other languages than C

On 2014-10-16, Nikos Mavrogiannopoulos wrote: > The currently proposed fedora maintainer instructions for the > system-wide crypto policy are mainly for the C language. Could some > experienced in other languages (e.g., ruby/python) propose some text for > them? > > https://fedoraproject.org/wiki

F-21 Branched report: 20141017 changes

Compose started at Fri Oct 17 07:15:03 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudcli

Re: Can you help with making fonts awesome in Fedora 21?

On 16 October 2014 15:14, Richard Hughes wrote: > If you maintain a font in Fedora, or are a provenpackager, I could > really need your help this weekend. Basically, we want to implement > AppStream metadata[1] for all the fonts we want to show in the > software center. I've already made a good s

Re: No more deltarpms by default

Am 17.10.2014 um 10:55 schrieb Roberto Ragusa: On 10/06/2014 07:25 PM, Reindl Harald wrote: the last discussions suggested that the result needs to be *identical* to the full RPM downloaded for not break signatures Bizarre design; the signature should protect the content (uncompressed), not

Re: No more deltarpms by default

Am 17.10.2014 um 10:49 schrieb Roberto Ragusa: On 10/06/2014 07:57 PM, Reindl Harald wrote: oh no - don't tie all together for reasons which did not destory the world over years - it is a damned good design that the part dealing with rpm packages don't need to know anything aboutt delta rpms

Re: No more deltarpms by default

On 10/06/2014 07:25 PM, Reindl Harald wrote: > the last discussions suggested that the result needs to be *identical* to the > full RPM downloaded for not break signatures Bizarre design; the signature should protect the content (uncompressed), not the transport method (compressed). -- Robe

[Bug 1153977] perl-Module-Path-0.15 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1153977 --- Comment #1 from Petr Pisar --- This is a bug-fix release suitable for F ≥ 21. -- 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=gY6tuQnFuR&a=cc_

Re: No more deltarpms by default

On 10/06/2014 07:57 PM, Reindl Harald wrote: > > oh no - don't tie all together for reasons which did not destory the world > over years - it is a damned good design that the part dealing with rpm > packages don't need to know anything aboutt delta rpms because the normal > packages are created

Re: Dash as default shell

On 8 October 2014 12:35, Miloslav Trmač wrote: Been away for a week and come back to this nonsense. Why put so much effort into arguing *against* having the right interpreter listed at the top of a script. Seems pretty perverse to insist it should be /bin/sh to maintain a conflation that's unique

Re: enhancing crypto policies for other languages than C

On 2014-10-16, Nikos Mavrogiannopoulos wrote: > The currently proposed fedora maintainer instructions for the > system-wide crypto policy are mainly for the C language. Could some > experienced in other languages (e.g., ruby/python) propose some text for > them? > > https://fedoraproject.org/wiki

Re: Django-1.7 for Fedora 21

On 16/10/14 15:32, Stephen Gallagher wrote: > There are no Django applications that are part of the install sets of > any of the Products or Spins so far as I am aware, so the risk to the > Project deliverable dates would be minimal. I'd suggest bringing it to > FESCo for a more complete risk-anal

Re: Review swap

> I am still in need of a reviewer. Who can help me out? I'm willing > to review for you in exchange. > -- > I will take it later today, if nobody beat me to it :) Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Cond