On Tue, Jul 10, 2018 at 2:43 PM, Jason L Tibbitts III wrote:
> I guess that has to be another of those "nobody
> can touch this" packages.
Hey, c'mon, Ceph doesn't bite (that badly...)
Seriously though, we do maintain ceph.spec upstream in
http://github.com/ceph/ceph, in coordination with SUSE
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-07-12 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Thursday ==
2018-07-12 09:00 PDT US/Pacific
2018-07-12
Hello all,
All Haskell packages seem to be broken now, e.g., ghc-optional-args [1] or
anything on koschei [2]. They all fail like this:
+ ghc --make -no-user-package-db -dynamic Setup
[1 of 1] Compiling Main ( Setup.hs, Setup.o )
Linking Setup ...
/usr/lib/gcc/x86_64-redhat-linux/8/.
* Kevin Fenzi [11/07/2018 12:47] :
>
> Barring that, I think we will just continue to have people make changes
> and them get overwritten.
Does this include changes that were made for security reasons (disabling
a compile-time option, doing a dangerous chown/chmod call, ...)?
If so, I'm not very c
On Wed, Jul 11, 2018 at 12:47:40PM -0700, Kevin Fenzi wrote:
> The guidelines currently say:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity
>
> "Fedora's git repository is the canonical location for Fedora spec
> files. Maintainers MUST expect that other m
Ben Rosser wrote:
> Only if you consider packaging metadata to be part of "the code base".
> I guess that's the crux of the issue, some people want to treat it
> this way and others don't.
Packaging metadata has no business being part of the upstream code. Even for
code bases where I am both the
On 07/10/2018 10:41 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 10, 2018 at 10:28:40PM +0200, Florian Weimer wrote:
On 07/10/2018 10:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote:
On 07/03/2018 10:13 AM, Jan Kurik wrote:
= Prop
On Wed, 2018-07-11 at 19:03 +, rawh...@fedoraproject.org wrote:
> According to the schedule [1], Fedora 27 Candidate Update-20180711.1812 is now
> available for testing.
Uhhh...OK?
This obviously shouldn't have happened. I'm not sure what this compose
is or why it somehow passed all the
On 07/11/2018 12:57 PM, Mikolaj Izdebski wrote:
> On 07/11/2018 09:26 PM, Kevin Fenzi wrote:
>> On 07/11/2018 10:53 AM, Mikolaj Izdebski wrote:
>>> On 07/11/2018 07:31 PM, Andrew Lutomirski wrote:
On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izdebski
wrote:
>
> The slowest parts of
On Wed, Jul 11, 2018 at 3:42 PM, Josh Boyer wrote:
> I disagree. "Ownership" within Fedora is one aspect we've tried to
> address, but we're pretending that Fedora "owns" the code base which
> is a falsity. There are many more people involved and in this
> specific kind of situation, pretending
On Wed, Jul 11, 2018 at 08:27:22PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 11, 2018 at 12:26:01PM -0700, Kevin Fenzi wrote:
> > On 07/11/2018 10:53 AM, Mikolaj Izdebski wrote:
> > > On 07/11/2018 07:31 PM, Andrew Lutomirski wrote:
> > >> On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izd
On Wed, Jul 11, 2018 at 12:26:01PM -0700, Kevin Fenzi wrote:
> On 07/11/2018 10:53 AM, Mikolaj Izdebski wrote:
> > On 07/11/2018 07:31 PM, Andrew Lutomirski wrote:
> >> On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izdebski
> >> wrote:
> >>>
> >>> The slowest parts of setting up chroot is writing pac
On Mon, 2018-07-09 at 21:17 -0500, Rex Dieter wrote:
> See bug https://bugzilla.redhat.com/1599521
>
> Haven't been able to successfully build anything in rawhide recently.
FreeIPA folks also having trouble:
https://bugzilla.redhat.com/show_bug.cgi?id=1600035
--
Adam Williamson
Fedora QA Commu
On Wed, Jul 11, 2018 at 2:13 PM Matthew Miller wrote:
>
> On Wed, Jul 11, 2018 at 01:39:51PM -0400, Ben Rosser wrote:
> > We have been telling people for a while now that they don't "own"
> > their packages. Making it easier for people to maintain their packages
> > outside of dist-git and (effect
On 07/11/2018 09:26 PM, Kevin Fenzi wrote:
> On 07/11/2018 10:53 AM, Mikolaj Izdebski wrote:
>> On 07/11/2018 07:31 PM, Andrew Lutomirski wrote:
>>> On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izdebski
>>> wrote:
The slowest parts of setting up chroot is writing packages to disk,
syn
On Wed, Jul 11, 2018 at 02:12:37PM -0400, Matthew Miller wrote:
> On Wed, Jul 11, 2018 at 01:39:51PM -0400, Ben Rosser wrote:
> > We have been telling people for a while now that they don't "own"
> > their packages. Making it easier for people to maintain their packages
> > outside of dist-git and
On Wed, Jul 11, 2018 at 1:40 PM Ben Rosser wrote:
>
> On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer
> wrote:
> > Because nobody is communicating with upstream and fixing it there. In
> > some cases it'll be met with a shrug (like changelogs). In many, it
> > might actually result in upstream ma
On 07/11/2018 10:39 AM, Ben Rosser wrote:
> On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer
> wrote:
>> Because nobody is communicating with upstream and fixing it there. In
>> some cases it'll be met with a shrug (like changelogs). In many, it
>> might actually result in upstream making a similar
On 07/11/2018 10:53 AM, Mikolaj Izdebski wrote:
> On 07/11/2018 07:31 PM, Andrew Lutomirski wrote:
>> On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izdebski
>> wrote:
>>>
>>> The slowest parts of setting up chroot is writing packages to disk,
>>> synchronously. This part can be speeded up a lot by en
On Wed, Jul 11, 2018 at 11:01 AM, Chris Murphy wrote:
> The proposal suggests using zram device for swap, but doesn't say if
> there will be a secondary swap on disk.
>
> Zram uses memory rather than a drive partition as backing, so it's
> useful for /tmp instead of tmpfs; and also when there isn'
According to the schedule [1], Fedora 27 Candidate Update-20180711.1812 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan
Test coverage informatio
Hi all,
We are delaying the mass rebuild as people are still working on
binutils 2.31 change (https://fedoraproject.org/wiki/Changes/BINUTILS231).
At this point, we want to re-evaluate the situation on Friday, 13 July 2018
and
based on where we are, we will either proceed with the mass rebuild or
On Wed, Jul 11, 2018 at 01:39:51PM -0400, Ben Rosser wrote:
> We have been telling people for a while now that they don't "own"
> their packages. Making it easier for people to maintain their packages
> outside of dist-git and (effectively) ignore changes from
> proven-packagers seems to take us in
On 07/11/2018 07:31 PM, Andrew Lutomirski wrote:
> On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izdebski
> wrote:
>>
>> On 07/11/2018 06:37 PM, Andrew Lutomirski wrote:
>>> From my perspective as an occasional Fedora packager, I'm regularly
>>> surprised by just how long it takes for Koji builders t
On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer wrote:
> Because nobody is communicating with upstream and fixing it there. In
> some cases it'll be met with a shrug (like changelogs). In many, it
> might actually result in upstream making a similar fix.
What is "upstream", though? Some repository
On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izdebski wrote:
>
> On 07/11/2018 06:37 PM, Andrew Lutomirski wrote:
> > From my perspective as an occasional Fedora packager, I'm regularly
> > surprised by just how long it takes for Koji builders to install
> > dependencies. I've never tried to dig in
Jan Kratochvil wrote:
> There is no C/C++ language. There are two orthogonal languages, C and
> C++. (And some people say C++11 and C++03 are also orthogonal.)
Yes, C and C++ are divergent languages (I wouldn't call them "orthogonal",
but they are definitely different things), but gcc-c++ curren
On Wed, Jul 11, 2018 at 12:16:45PM -0400, Josh Boyer wrote:
>
> > maintain their specs wherever they want, but they should be prepared that
> > Fedora will change their specs and they should not overwrite such changes.
>
> I said that as well. What you're missing is the part where people
> tell
On 07/11/2018 10:01 AM, Jan Kratochvil wrote:
> On Wed, 11 Jul 2018 18:26:23 +0200, Josh Stone wrote:
>> So I hear you like compile-time safety...
>>
>> No, I don't seriously want to get into a language comparison here,
>> except to say that it's reasonable for the world to expand beyond C/C++,
>
The proposal suggests using zram device for swap, but doesn't say if
there will be a secondary swap on disk.
Zram uses memory rather than a drive partition as backing, so it's
useful for /tmp instead of tmpfs; and also when there isn't a swap
partition on the local drive.
But if there is a backin
On 07/11/2018 06:37 PM, Andrew Lutomirski wrote:
> From my perspective as an occasional Fedora packager, I'm regularly
> surprised by just how long it takes for Koji builders to install
> dependencies. I've never tried to dig in too far, but it looks like the
> builders download package metadata,
On Wed, Jul 11, 2018, at 12:37 PM, Andrew Lutomirski wrote:
>
> (Hmm. Some future version of rpm/dnf could get really fancy and
> *reflink*
> package contents into the build chroot rather than untarring them every
> time.)
Try `rpm-ostree ex container` today and see just how fast it is to con
On Wed, 11 Jul 2018 18:26:23 +0200, Josh Stone wrote:
> So I hear you like compile-time safety...
>
> No, I don't seriously want to get into a language comparison here,
> except to say that it's reasonable for the world to expand beyond C/C++,
There is no C/C++ language. There are two orthogonal
On Tue, Jul 10, 2018 at 1:13 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Tue, Jul 10, 2018 at 06:03:33PM +0200, Igor Gnatenko wrote:
> > On Tue, Jul 10, 2018 at 5:52 PM Kevin Kofler
> wrote:
> >
> > > Igor Gnatenko wrote:
> > > > As per Changes/Remove GCC from BuildRoot
> > >
On 07/11/2018 07:37 AM, Kevin Kofler wrote:
> Igor Gnatenko wrote:
>> A lot of packages in 2018 are not written in C/C++
>
> … and this is the problem that needs fixing.
>
> It is just a PITA to have packages dragging in more and more interpreters
> and/or language runtimes. The slowness and lac
On Wed, 2018-07-11 at 16:37 +0200, Kevin Kofler wrote:
> Igor Gnatenko wrote:
> > A lot of packages in 2018 are not written in C/C++
>
> … and this is the problem that needs fixing.
>
> It is just a PITA to have packages dragging in more and more interpreters
> and/or language runtimes. The slow
On Wed, Jul 11, 2018 at 11:58 AM Igor Gnatenko
wrote:
>
> On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer wrote:
>>
>> On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III
>> wrote:
>> >
>> > > "JB" == Josh Boyer writes:
>> >
>> > JB> That's impossible to enforce and unrealistic.
>> >
>> > I w
On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer
wrote:
> On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III
> wrote:
> >
> > > "JB" == Josh Boyer writes:
> >
> > JB> That's impossible to enforce and unrealistic.
> >
> > I will go as far as "it's somewhat difficult to enforce and idealistic",
On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III wrote:
>
> > "JB" == Josh Boyer writes:
>
> JB> That's impossible to enforce and unrealistic.
>
> I will go as far as "it's somewhat difficult to enforce and idealistic",
> but no further.
>
> JB> We can say that as much as we'd like, but
> "JB" == Josh Boyer writes:
JB> That's impossible to enforce and unrealistic.
I will go as far as "it's somewhat difficult to enforce and idealistic",
but no further.
JB> We can say that as much as we'd like, but there is nothing we can do
JB> to prevent people from syncing from elsewhere.
Igor Gnatenko wrote:
> A lot of packages in 2018 are not written in C/C++
… and this is the problem that needs fixing.
It is just a PITA to have packages dragging in more and more interpreters
and/or language runtimes. The slowness and lack of compile-time type safety
of interpreted languages a
My apologies; after closer inspection I see that dpkg is a false
positive. It does match "^Vendor:" but that string occurs inside of a
here-document within a section. Will improve the scripting to only look
for tags when the rpm parser will be outside of section context.
I did fix the other issu
On 11.07.2018 11:35, Sandro Mani wrote:
Hi
I'm updating podofo to version 0.9.6 in rawhide. It carries a soname
bump (libpodofo.so.0.9.5 -> libpodofo.so.0.9.6), but all affected
packages build without changes against the new version [1]. I'll
rebuild all affected packages:
calibre
gimager
Greetings,
This e-mail is intended to inform you about the upcoming Bugzilla changes
happening on 2018-08-14 (Rawhide bug rebase) and what you need to do,
if anything.
We will be automatically changing the version for most rawhide bugs to
Fedora 29.
This will result in regular bugs reported again
An Update on Flock
* New Sponsor
Some of you may have noticed that the ARM Foundation is now a Gold Sponsor
for Flock.
* Tickets and T-shirts
My tardiness at getting t-shirts ordered is to your BENEFIT. The tickets
that have t-shirts associated with them have been extended until tomorrow,
12 J
On Tue, Jul 10, 2018 at 8:27 PM Jason L Tibbitts III wrote:
>
> Unfortunately it seems that many of these packages have had the
> BuildRoot tags _added back in_ after previously having them removed. A
> number of the commits even delete existing changelog entries, a sure
> sign that someone is ju
= Proposed self contained change =
https://fedoraproject.org/wiki/Changes/Update_comps_to_use_python3
* Owner:
churchyard
Change the comps groups python-classroom, engineering-and-scientific,
development-libs, cloud-management, font-design, mysql,
robotics-suite, authoring-and-publishing and elec
On Wed, 11 Jul 2018 14:00:40 +0200
mskal...@redhat.com wrote:
> Hi,
> during a discussion with upstream (MongoDB) they asked me about
> default Fedora C/C++ build flags. And I don't remember all Fedora
> System Wide changes where it was introduced,... so is there some
> place where it's described?
Hi,
during a discussion with upstream (MongoDB) they asked me about default
Fedora C/C++ build flags. And I don't remember all Fedora System Wide
changes where it was introduced,... so is there some place where it's
described?
Main upstream question was:
"""
I don't know what is in those various h
On Tue, 2018-07-10 at 08:42 +0100, Tomasz Kłoczko wrote:
> On Tue, 10 Jul 2018 at 06:37, David Tardon
> wrote:
> [..]
> > > My proposition is *not* to add gcc/g++ explicit to BuildReequires
> > > and
> > > use instead glibc-devel and libstdc++-devel modifications and ban
> > > use
> > > gcc/gcc-c+
On 10 July 2018 at 12:30, Aleksandar Kurtakov wrote:
> eclipse-xtext and its dependencies eclipse-xpand and eclipse-emf-mwe have
> just been orphaned. Eclipse SIG has no use of these packages anymore
> (despite them being really active upstream), the build system is quite
> complicated and they h
On Wed, Jul 11, 2018 at 10:44 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Wed, Jul 11, 2018 at 08:33:36AM +0100, Peter Robinson wrote:
>> >> = Proposed System Wide Change: ZRAM support for ARM images =
>> >> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
>> >>
>> >>
>> >> Owner(s):
>> >>
On Wed, Jul 11, 2018 at 10:30:39AM +0100, Peter Robinson wrote:
> >> >> > Move to uEFI as the default boot mechanism for ARMv7 devices.
> >> >>
> >> >> Will this work with virt-manager too? Currently, while aarch64 boots via
> >> >> uEFI there, it seems that armv7 is only supported by manually spec
On Wed, Jul 11, 2018 at 08:33:36AM +0100, Peter Robinson wrote:
> >> = Proposed System Wide Change: ZRAM support for ARM images =
> >> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
> >>
> >>
> >> Owner(s):
> >> * Peter Robinson
> >>
> >>
> >> Enable ZRAM for swap on ARMv7 and aarch64 p
On Tue, Jul 10, 2018 at 9:43 PM, Jason L Tibbitts III wrote:
> The packaging guidelines indicate that the following tags must not be
> used:
> Copyright:
> Packager:
> Vendor:
> PreReq:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
>
> I wasn't aware that a packag
Hi
I'm updating podofo to version 0.9.6 in rawhide. It carries a soname
bump (libpodofo.so.0.9.5 -> libpodofo.so.0.9.6), but all affected
packages build without changes against the new version [1]. I'll rebuild
all affected packages:
calibre
gimagereader
krename
scribus
vfrnav
Sandro
[1] h
>> >> > Move to uEFI as the default boot mechanism for ARMv7 devices.
>> >>
>> >> Will this work with virt-manager too? Currently, while aarch64 boots via
>> >> uEFI there, it seems that armv7 is only supported by manually specifying
>> >> a kernel and initrd.
>> >
>> > Ping.
>>
>> Ping? Who or wha
On Wed, Jul 11, 2018 at 09:03:27AM +0100, Peter Robinson wrote:
> On Tue, Jul 10, 2018 at 9:22 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
> >> On 07/03/2018 05:15 AM, Jan Kurik wrote:
> >> > Move to uEFI as the default boot mechanism
09.07.2018, 20:34, "Pete Walter" :
> Hi,
>
> I'm updating icu to 62.1 in rawhide and rebuilding anything that links with
> libicu. We'll also have a compat package with libicu 61 soname, so I don't
> expect much rawhide breakage: anything that is currently built with libicu 61
> but fails to bui
On Tue, Jul 10, 2018 at 10:50 PM, Kevin Fenzi wrote:
> On 07/03/2018 05:39 AM, Jan Kurik wrote:
>> = Proposed System Wide Change: ZRAM support for ARM images =
>> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
>>
>>
>> Owner(s):
>> * Peter Robinson
>>
>>
>> Enable ZRAM for swap on ARMv
On Wed, Jul 11, 2018 at 8:50 AM, Peter Robinson wrote:
> On Tue, Jul 10, 2018 at 10:50 PM, Kevin Fenzi wrote:
>> On 07/03/2018 05:39 AM, Jan Kurik wrote:
>>> = Proposed System Wide Change: ZRAM support for ARM images =
>>> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
>>>
>>>
>>> Owner(
On Wed, Jul 11, 2018 at 12:13 AM, Kyle Marek wrote:
> On 07/10/2018 04:51 PM, Cole Robinson wrote:
>> On 07/10/2018 04:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
On 07/03/2018 05:15 AM, Jan Kurik wrote:
> Move to uEFI as the
On Tue, Jul 10, 2018 at 9:51 PM, Cole Robinson wrote:
> On 07/10/2018 04:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
>>> On 07/03/2018 05:15 AM, Jan Kurik wrote:
Move to uEFI as the default boot mechanism for ARMv7 devices.
>>>
>>
On Tue, Jul 10, 2018 at 9:22 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
>> On 07/03/2018 05:15 AM, Jan Kurik wrote:
>> > Move to uEFI as the default boot mechanism for ARMv7 devices.
>>
>> Will this work with virt-manager too? Currently,
>> = Proposed System Wide Change: ZRAM support for ARM images =
>> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
>>
>>
>> Owner(s):
>> * Peter Robinson
>>
>>
>> Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to
>> improve performance and reliability on ARM Single Board
65 matches
Mail list logo