On Tue, Oct 09, 2018 at 06:07:44PM -0600, Al Stone wrote:
> On 10/3/18 9:53 PM, Christopher wrote:
> > I'm still very confused about how to do modular packaging in Fedora. I
> > don't know:
> >
> > 1. How do I create a module for a new Fedora package?
> > 2. How do I create a module for my existin
Hi,
I'd like Fedora and FPC in general to agree to a general layout for
macros and their associated material like templates, so the next step
can focus on the actual macros and their documentation, and not on how
the result is shipped to users.
https://pagure.io/packaging-committee/issue/813
Hi all,
I tried upgrading my system to f29, and I noticed some packages that
would have been downgraded. Upon further investigation, their
maintainers seem to have forgotten (or missed) to build and/or submit
updates for these packages to fedora 29 - so, for example, the newer
version is only avai
Il giorno mer 10 ott 2018 alle ore 13:58 Fabio Valentini
ha scritto:
> I seem to
> remember that package versions should always be higher in newer fedora
> releases (so there are no downgrades when upgrading from N to N+1). Is
> this what is referred to as a "broken upgrade path"?
Exactly
___
Shouldn't this be caused by F29 final freeze?
On 10.10.2018 13:57, Fabio Valentini wrote:
Hi all,
I tried upgrading my system to f29, and I noticed some packages that
would have been downgraded. Upon further investigation, their
maintainers seem to have forgotten (or missed) to build and/or sub
On Tue, Oct 9, 2018 at 8:21 PM Reindl Harald wrote:
>
> nice for you, other prefer email and *local* archives which sirely don't
> disappear *because* you control the whole client and if somebody next
> year makes a relaunch of the online stuff with a bad usability or
> lacking features you are do
On Wed, Oct 10, 2018 at 2:57 PM Michal Konečný wrote:
>
> Shouldn't this be caused by F29 final freeze?
Not necessarily. The freeze went into effect only yesterday, so it's
not that (yet).
The specific packages I listed don't have newer versions available,
even in f29-updates-testing.
As I said,
On Wed, Oct 10, 2018 at 03:10:23PM +0200, Fabio Valentini wrote:
> On Wed, Oct 10, 2018 at 2:57 PM Michal Konečný wrote:
> >
> > Shouldn't this be caused by F29 final freeze?
>
> Not necessarily. The freeze went into effect only yesterday, so it's
> not that (yet).
>
> The specific packages I li
On Wed, Oct 10, 2018 at 1:59 PM Fabio Valentini
wrote:
> I haven't been able to find the documentation for this, but I seem to
> remember that package versions should always be higher in newer fedora
> releases (so there are no downgrades when upgrading from N to N+1). Is
> this what is referred
Hibernating my Lenovo ThinkPad T400 fails frequently because of issues with the
installed card reader:
https://bugzilla.redhat.com/show_bug.cgi?id=1638014
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...
Il giorno mer 10 ott 2018 alle ore 15:46 Kamil Paral
ha scritto:
> That policy has been cancelled. Since the upgrade tools started doing
> basically "dnf distrosync (--allowerasing)" for upgrades, the upgrade path
> between distros stopped being a major issue and the policy has been dropped.
Do
On Wednesday, 10 October 2018 14.45.22 WEST Kamil Paral wrote:
> That policy has been cancelled. Since the upgrade tools started doing
> basically "dnf distrosync (--allowerasing)" for upgrades, the upgrade path
> between distros stopped being a major issue and the policy has been
> dropped.
Even
I've just orphaned Java packages listed below. All of them are leaf
packages - not required or buildrequired by anything that I know of.
I divided these packages into 3 groups:
Group 1: packages that were only orphaned and are still active in all
branches, including master; they may be still usef
On Wed, Oct 10, 2018 at 4:33 PM Germano Massullo
wrote:
> Il giorno mer 10 ott 2018 alle ore 15:46 Kamil Paral
> ha scritto:
> > That policy has been cancelled. Since the upgrade tools started doing
> basically "dnf distrosync (--allowerasing)" for upgrades, the upgrade path
> between distros st
On Tue, Oct 09, 2018 at 06:07:44PM -0600, Al Stone wrote:
>-- And the one question I have to add on to Christopher's wonderful
> list: I have a package where upstream releases about once a month,
> and each new release must by definition be backwards compatible
> (acpica-tools
On Wed, Oct 10, 2018 at 3:15 PM Matthew Miller wrote:
>
> On Tue, Oct 09, 2018 at 06:07:44PM -0600, Al Stone wrote:
> >-- And the one question I have to add on to Christopher's wonderful
> > list: I have a package where upstream releases about once a month,
> > and each new release
On Wed, Oct 10, 2018 at 3:15 PM Matthew Miller wrote:
>
> On Tue, Oct 09, 2018 at 06:07:44PM -0600, Al Stone wrote:
> >-- And the one question I have to add on to Christopher's wonderful
> > list: I have a package where upstream releases about once a month,
> > and each new release
On Wed, Oct 10, 2018 at 03:17:13PM -0400, Neal Gompa wrote:
> I still don't get why this subset case requires all the extra module
> goop? Couldn't we just have fedpkg have an "fedpkg build
> --all-releases" switch to just trigger on the same commit for all
> releases?
It does seem like something
On Wed, Oct 10, 2018 at 03:28:02PM -0400, Ben Rosser wrote:
> My understanding-- from skimming the documentation a few times and
> reading discussions about modularity-- is that I'd now need to keep
> track of two dist-git repositories, and two different metadata files.
> This feels like a lot of e
On Wed, Oct 10, 2018 at 3:46 PM Matthew Miller wrote:
>
> On Wed, Oct 10, 2018 at 03:17:13PM -0400, Neal Gompa wrote:
> > I still don't get why this subset case requires all the extra module
> > goop? Couldn't we just have fedpkg have an "fedpkg build
> > --all-releases" switch to just trigger on
On Wed, Oct 10, 2018 at 03:54:18PM -0400, Stephen Gallagher wrote:
> > It does seem like something like that should be possible.
> This is possible already, due to a fedpkg update a couple months ago:
> https://docs.pagure.org/fedpkg/releases/1.35.html
Do we have policy around that?
One reason on
Works on my Dell XPS 15 9550. But contrary to normal suspend, this takes quite
long for the machine to shut down. It was about 25 seconds and my 16 GB RAM was
used up to 8 GB, but still 25 seconds are a bit long for an SSD.
___
devel mailing list -- dev
On 11/10/18 01:50, José Abílio Matos wrote:
Even so the problem described seems to be related with packages that were not
build for F29 by mistake (probably around the time that F29 was branched from
rawhide August 14). If the same nvr exists in F28 and rawhide it is difficult
to come with a reas
Works on my Dell XPS 15 9550. But contrary to normal suspend, this takes quite
long for the machine to shut down. It was about 25 seconds and my 16 GB RAM was
used up to 8 GB, but still 25 seconds are a bit long for an SSD.
And I have to say that it killed my `rpm-ostree upgrade` on my F29SB, wh
Works on my Dell XPS 15 9550. But contrary to normal suspend, this takes quite
long for the machine to shut down. It was about 25 seconds and my 16 GB RAM was
used up to 8 GB, but still 25 seconds are a bit long for an SSD.
And I have to say that it killed my `rpm-ostree upgrade` on my F29SB, wh
Hi,
sorry for the late response :(
On Tue, Oct 2, 2018 at 9:42 AM Richard W.M. Jones wrote:
> On Mon, Oct 01, 2018 at 11:26:59AM +0200, Miroslav Vadkerti wrote:
> > For this time I rescheduled the run:
> >
> >
> >
> https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/
OLD: Fedora-29-20181009.n.0
NEW: Fedora-29-20181010.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of upgraded
> "KP" == Kamil Paral writes:
KP> That policy has been cancelled. Since the upgrade tools started
KP> doing basically "dnf distrosync (--allowerasing)" for upgrades, the
KP> upgrade path between distros stopped being a major issue and the
KP> policy has been dropped.
If this is true then it'
On Wed, Oct 10, 2018 at 7:41 PM Jason L Tibbitts III wrote:
>
> > "KP" == Kamil Paral writes:
>
> KP> That policy has been cancelled. Since the upgrade tools started
> KP> doing basically "dnf distrosync (--allowerasing)" for upgrades, the
> KP> upgrade path between distros stopped being a ma
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-10-11 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Thursday ==
2018-10-11 09:00 PDT US/Pacific
2018-10-1
30 matches
Mail list logo
