Hi,
> It's easier on implementation. That's the main reason. I generally
> believe that
> what's easier on implementation is better.
It's maybe easier on the copr side, but not for the copr users ...
If you can modify the upstream project (either because you are
upstream, or in case upstream
Hello Gerd,
On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann wrote:
> Hi,
>
> > It's easier on implementation. That's the main reason. I generally
> > believe that
> > what's easier on implementation is better.
>
> It's maybe easier on the copr side, but not for the copr users ...
>
> If you can
2017-09-01 11:20 GMT+02:00 Gerd Hoffmann :
> So, what would be really helpful, especially for CI with the option to
> build and test every upstream commit, would be support for *two* git
> repos. One git repo where the spec-file and other build-related stuff
> lives (distgit like). One git repo w
Hey Marc,
On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck)
wrote:
> Quack,
>
> On 09/01/2017 01:28 AM, Michal Novotny wrote:
>
> > But I think an off-line talk might be the best. Depends on you.
>
> I can understand you don't want this thread to end-up in flames, and yes
> sometimes it helps
Hi,
I hope that soon the first Cockpit add-on appears in the Fedora
repositories. Cockpit can find such add-ons via their AppStream
metainfo data, similar to how GNOME Software finds applications to
install for a desktop environment.
Thus, we would need to install the appstream-data package also
On Fri, Sep 1, 2017 at 6:37 AM, Marius Vollmer
wrote:
> Hi,
>
> I hope that soon the first Cockpit add-on appears in the Fedora
> repositories. Cockpit can find such add-ons via their AppStream
> metainfo data, similar to how GNOME Software finds applications to
> install for a desktop environmen
On 31 August 2017 at 22:09, Matthew Miller wrote:
> On Thu, Aug 31, 2017 at 08:11:56PM +1000, Nick Coghlan wrote:
>> > I'd think the solution is simply to mark your module with "Service
>> > Level: alpha" (and then we'd want some tooling where SL-alpha and
>> > SL-beta modules only show up for tho
Hi,
> Right, this is cool. The problem is that the upstream repo would need
> to be configured to provide a public message that something has been
> changed
> in it (i.e. new release) so the question is how to do this part.
Ah, right, setting up a webhook needs access to the upstream repo too.
Neal Gompa writes:
>> So, what about creating a dedicated appstream-data-server package that
>> carries only those components that we want to see on a Server?
>>
>> Initially, it would contain only components of type "addon" that extend
>> "cockpit.desktop", and components of type "service".
>
>
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
wrote:
> Neal Gompa writes:
>
>>> So, what about creating a dedicated appstream-data-server package that
>>> carries only those components that we want to see on a Server?
>>>
>>> Initially, it would contain only components of type "addon" that exten
Marius Vollmer wrote:
> Neal Gompa writes:
>
>>> So, what about creating a dedicated appstream-data-server package that
>>> carries only those components that we want to see on a Server?
>>>
>>> Initially, it would contain only components of type "addon" that extend
>>> "cockpit.desktop", and co
I'm trying to build ceph-12.2.0 for f28, So far the build has failed twice on
armv7hl during %install trying to install a file that was seeminlyly
successfully built.
That's two different files. The first time it was cephfs-journal-tool, the
second time it was the one immediately after: cephf
On Fri, Sep 1, 2017 at 1:41 PM, Gerd Hoffmann wrote:
> Hi,
>
> > Right, this is cool. The problem is that the upstream repo would need
> > to be configured to provide a public message that something has been
> > changed
> > in it (i.e. new release) so the question is how to do this part.
>
> Ah
On Fri, Sep 01, 2017 at 08:17:11AM -0400, Kaleb Keithley wrote:
>
> I'm trying to build ceph-12.2.0 for f28, So far the build has failed twice
> on armv7hl during %install trying to install a file that was seeminlyly
> successfully built.
>
> That's two different files. The first time it was c
On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
wrote:
Neal Gompa writes:
So, what about creating a dedicated appstream-data-server package that
carries only those components that we want to see on a Server?
Initially, it would contain only components o
On Fri, Sep 1, 2017 at 8:37 AM, Alexander Bokovoy wrote:
> On pe, 01 syys 2017, Neal Gompa wrote:
>>
>> On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
>> wrote:
>>>
>>> Neal Gompa writes:
>>>
> So, what about creating a dedicated appstream-data-server package that
> carries only those co
On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 8:37 AM, Alexander Bokovoy wrote:
On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
wrote:
Neal Gompa writes:
So, what about creating a dedicated appstream-data-server package that
carries
On Fri, Sep 1, 2017 at 8:57 AM, Alexander Bokovoy wrote:
> On pe, 01 syys 2017, Neal Gompa wrote:
>>
>> On Fri, Sep 1, 2017 at 8:37 AM, Alexander Bokovoy
>> wrote:
>>>
>>> On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
wrote:
>
>
Neal Gompa writes:
> Implement your AppStream filter at the application level, rather than
> messing with appstream-data package.
Yes, of course. Cockpit will do the right thing even with the full
appstream-data package. This is only about not having 15 MiB of useless
data installed.
I have n
On Fri, Sep 1, 2017 at 9:03 AM, Richard Hughes wrote:
> On Fri, Sep 1, 2017 at 2:00 PM, Neal Gompa wrote:
>> It's not just about your vision of usage, it's about how everyone else
>> uses it too! :)
>
> Well, we could do the opposite, we could just include cockpit data in
> appstream-data and the
Neal Gompa writes:
> [...] It's already kind of second-class in Fedora because it's not
> properly integrated into our repodata (like it's supposed to be, and
> how it is in openSUSE, Mageia, and even in COPR).
>
> We should be making AppStream data support first-class, not
> third-class. :(
Thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2017-09-01 at 16:01 +0300, Marius Vollmer wrote:
> Neal Gompa writes:
>
> > Implement your AppStream filter at the application level, rather
> > than
> > messing with appstream-data package.
>
> Yes, of course. Cockpit will do the right t
Is there any way to fix cmake or the ceph cmake rules so that they report
the real useful error message, instead of throwing it away & providing a
generic "cannot copy file" message with no details ?
Quick and dirty: prefix all commands with something like
strace -o "| grep '= -1'"
Examp
On Fri, Sep 1, 2017 at 9:12 AM, Marius Vollmer
wrote:
> Neal Gompa writes:
>
>> [...] It's already kind of second-class in Fedora because it's not
>> properly integrated into our repodata (like it's supposed to be, and
>> how it is in openSUSE, Mageia, and even in COPR).
>>
>> We should be making
Neal Gompa writes:
> All PackageKit based software managers automatically download the
> data, as the Dnf PK backend does this:
> https://github.com/hughsie/PackageKit/blob/master/backends/dnf/pk-backend-dnf.c#L553
Ahh, thanks! "pkcon refresh force" indeed downloads it for me.
> You can see th
Dne 1.9.2017 v 15:31 Neal Gompa napsal(a):
> On Fri, Sep 1, 2017 at 9:12 AM, Marius Vollmer
> wrote:
>> Neal Gompa writes:
>>
>>> [...] It's already kind of second-class in Fedora because it's not
>>> properly integrated into our repodata (like it's supposed to be, and
>>> how it is in openSUSE,
On Fri, Sep 01, 2017 at 09:25:22PM +1000, Nick Coghlan wrote:
> So the request is for there to be a way to indicate that a stream is
> available for explicit dependencies, but *shouldn't* be taken into
> account for implicit stream expansion yet. Then, once the low level
> stream is stable, *then*
Fedora Developers,
I am working on a way to provide concrete ABI/API assurances for
parts of the base runtime.
I've written up some of the key ideas here:
https://fedoraproject.org/wiki/BaseRuntimeInterface
Any feedback would be appreciated, including bikeshed on component
name prefix for frozen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2017-09-01 at 09:28 -0500, Carlos O'Donell wrote:
> Fedora Developers,
>
> I am working on a way to provide concrete ABI/API assurances for
> parts of the base runtime.
Note that Base Runtime is F26-only thing and in F27 it is called Host
an
Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2017-09-01 16:00 UTC'
Links to all issues below ca
Also new business:
#topic #1766 Is ImageMagick 7 appropriate for Fedora 27 (and even 28)?
.fesco 1766
https://pagure.io/fesco/issue/1766
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproje
On Thu, 31 Aug 2017 22:14:11 +0200, Björn 'besser82' Esser wrote:
> > It's been several hours since this entirely new package repo has been
> > created,
> > but the koji build still fails. How long does it take for koji to learn
> > about this new package?
> it takes as long someone from releng
On 01/09/17 17:26, Michael Schwendt wrote:
On Thu, 31 Aug 2017 22:14:11 +0200, Björn 'besser82' Esser wrote:
It's been several hours since this entirely new package repo has been created,
but the koji build still fails. How long does it take for koji to learn
about this new package?
it takes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
So I think F28/F29 would be best time for retiring YUM. Right now DNF
should be already stable and provide same capabilities (or documented
that something will not be supported).
Hopefully infrastructure / rel-eng folks will finally add support for
https://meetbot.fedoraproject.org/fedora-meeting/2017-09-01/fesco.2017-09-01-16.02.log.html
.
Meeting summary
---
* init process (jforbes, 16:02:16)
* #1761 Update of "Fedora Release Live Cycle" and "Changes / Policy"
(jforbes, 16:06:01)
* LINK: https://pagure.io/fesco/issue/17
On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> So I think F28/F29 would be best time for retiring YUM. Right now DNF
> should be already stable and provide same capabilities (or documented
> that something will not be supported).
>
> Ho
On Mon, 2017-08-28 at 20:39 -0500, Michael Cronenworth wrote:
> Rebuild status:
> * All F25/F26 packages have been rebuilt against ImageMagick 6.9.9.9
> * Most of the F27+ packages have been rebuilt with the following exceptions:
> - cuneiform
> FTBFS since Fedora 23, last upstream release is
On 09/01/2017 12:01 PM, Igor Gnatenko wrote:
Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!
AFAIK there is still no way to get dependency information out of DNF.
(There may be a way to do i
On 2017-09-01 1:01 PM, Igor Gnatenko wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
So I think F28/F29 would be best time for retiring YUM. Right now DNF
should be already stable and provide same capabilities (or documented
that something will not be supported).
Hopefully infrastructure
On Fri, Sep 01, 2017 at 02:38:59PM -0400, Fernando Nasser wrote:
> 1) Can we use existing repositories created with yum createrepo with dnf?
Yes.
> 2) Are "groups" supported? (E.g.: yum instalgroup xxx)
Yes.
--
Matthew Miller
Fedora Project Leader
On 2017-09-01 2:52 PM, Matthew Miller wrote:
On Fri, Sep 01, 2017 at 02:38:59PM -0400, Fernando Nasser wrote:
1) Can we use existing repositories created with yum createrepo with dnf?
Yes.
2) Are "groups" supported? (E.g.: yum instalgroup xxx)
Yes.
Thanks Matthew. I guess it will be just
Hi all,
At the moment the appstream-builder requires a 48x48px application
icon[1] to be included in the AppStream metadata. I'm sure it's no
surprise that 48x48 padded to 64x64 and then interpolated up to
128x128 (for HiDPI screens) looks pretty bad. For F28 and higher I'm
going to raise the mini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2017-09-01 at 13:56 -0400, Neal Gompa wrote:
> On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > So I think F28/F29 would be best time for retiring YUM. Right now
> > DNF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2017-09-01 at 13:30 -0500, Ian Pilcher wrote:
> On 09/01/2017 12:01 PM, Igor Gnatenko wrote:
> > Do you still have some critical missing functionality in DNF? And
> > let
> > us know reasons why would you like to keep YUM available (hopefully
On Fri, Sep 01, 2017 at 09:19:24PM +0200, Igor Gnatenko wrote:
> > There is still one thing I've noticed we're missing: API and CLI for
> > getting package changelogs[1]. This exists in yum but doesn't in dnf.
> While I agree that this is missing functionality, being honest I think
> we should educ
At the moment the appstream-builder requires a 48x48px application
icon[1] to be included in the AppStream metadata. I'm sure it's no
surprise that 48x48 padded to 64x64 and then interpolated up to
128x128 (for HiDPI screens) looks pretty bad.
Instead: magnify by 3x linear pixel replication (48
On 09/01/2017 02:21 PM, Igor Gnatenko wrote:
This is true and we have plans to implement this, but problem is that
we don't know how to represent data. When it is about installing some
packages -- it's more or less easy to show, but when upgrades /
downgrades are involved it becomes way more comp
Hi,
/*Igor Gnatenko*/ wrote on Fri, 01 Sep 2017 19:01:49 +0200:
<..>
Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!
I've not tried 'dnf remove --duplicates' yet, but if it behaves similar
On Fri, 2017-09-01 at 15:00 -0500, Ian Pilcher wrote:
> On 09/01/2017 02:21 PM, Igor Gnatenko wrote:
> > This is true and we have plans to implement this, but problem is
> > that
> > we don't know how to represent data. When it is about installing
> > some
> > packages -- it's more or less easy to
On Friday, 1 September 2017 21:30:44 CEST Matthew Miller wrote:
> RPM specfile changelogs are often of interest to systems
> administrators.
Agreed. Before I update a huge number of hosts I'd like to check the
changelogs for any possible trouble. This is the the main thing I miss in dnf
right n
Hi
I've got another weird situation: I wanted to get pjproject building
again, rebased and added necessary patches, did the scratch build, and
all looked good [1]. So I went ahead and committed the result, fired off
the build, but to my surprise that build failed while applying the
patches [2
Announcing the creation of a new nightly release validation test event
for Fedora 27 Branched 20170901.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
/*Igor Gnatenko*/ wrote on Fri, 01 Sep 2017 15:19:34 +0200:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2017-09-01 at 16:01 +0300, Marius Vollmer wrote:
Neal Gompa writes:
Implement your AppStream filter at the application level, rather
than
messing with appstream-data package.
Am 28.08.2017 um 22:28 schrieb Björn 'besser82' Esser:
Hello folks,
I'm planning to update jsoncpp on Rawhide and fc27 during the next
days. After the builds have landed, I'll take care of rebuilding all
consumers against the new so name. Since the API / ABI has no
publicly consumed symbols
On Fri, Sep 01, 2017 at 10:56:39PM +0200, Sandro Mani wrote:
> Hi
>
> I've got another weird situation: I wanted to get pjproject building
> again, rebased and added necessary patches, did the scratch build,
> and all looked good [1]. So I went ahead and committed the result,
> fired off the build
I think you've basically analyzed it correctly.
The patches have been added to the ‘sources’ file (and so are pulled
from the lookaside cache). This is of course wrong.
The new patches are in git, but these are overwritten by the lookaside
cache.
The easiest thing is to simply edit the ‘sour
On 09/01/2017 01:13 PM, Adam Williamson wrote:
FESCo decided at today's meeting that 7 should not go to F27 (unless it
can be made parallel installable and not used by anything release-
blocking by default), and to go into F28 there must be a system-wide
Change:
The libs are definitely parallel
On Fri, 2017-09-01 at 13:30 -0500, Ian Pilcher wrote:
> On 09/01/2017 12:01 PM, Igor Gnatenko wrote:
> > Do you still have some critical missing functionality in DNF? And
> > let
> > us know reasons why would you like to keep YUM available (hopefully
> > there are no)!
>
> AFAIK there is still no
On Sep 1, 2017 3:31 PM, "Matthew Miller" wrote:
On Fri, Sep 01, 2017 at 09:19:24PM +0200, Igor Gnatenko wrote:
> > There is still one thing I've noticed we're missing: API and CLI for
> > getting package changelogs[1]. This exists in yum but doesn't in dnf.
> While I agree that this is missing fu
On 09/01/2017 12:46 PM, Tom Hughes wrote:
> On 01/09/17 17:26, Michael Schwendt wrote:
>> On Thu, 31 Aug 2017 22:14:11 +0200, Björn 'besser82' Esser wrote:
>>
It's been several hours since this entirely new package repo has
been created,
but the koji build still fails. How long does
60 matches
Mail list logo
