On 1/14/20 9:00 AM, Luya Tshimbalanga wrote:
On 2020-01-13 12:56 a.m., Benson Muite wrote:
On 1/12/20 9:38 AM, Luya Tshimbalanga wrote:
The challenge about upstream is when they lack activity for years
and contributions are very difficult when users lack knowledge of
coding without proper g
On 2020-01-13 12:56 a.m., Benson Muite wrote:
On 1/12/20 9:38 AM, Luya Tshimbalanga wrote:
The challenge about upstream is when they lack activity for years and
contributions are very difficult when users lack knowledge of coding
without proper guidance. For example, attempting to improve say
Many of us deeply involved in RHEL's production are excited about this
idea. We are looking for ways to do more of the RHEL 9 creation
activities in public and this could help serve that purpose.
Something along these lines would be fantastic because identical
Fedora sources could be used to produ
Hey Fabio and Silvia ,
As I'm an pretty bad when it comes to composing a message , I'll just
write it out in points
1.Thanks for replying .
2. Sorry Silvia I got you confused as well , as Fabio pointed out ,
pantheon is dependent on gnome .Thanks Fabio for clearing it out .
3. Fabio, I don't know
Dear all,
You are kindly invited to the meeting:
Modularity Team (weekly) on 2020-01-14 from 15:00:00 to 16:00:00 UTC
At fedora-meetin...@irc.freenode.net
The meeting will be about:
Meeting of the Modularity Team.
More information available at: [Modularity Team
Docs](https://docs.pagure.o
On 13. 01. 20 22:54, Adam Williamson wrote:
On Sun, 2020-01-12 at 23:24 +0100, Miro Hrončok wrote:
Please don't mention it as required or even necessarily recommended, as
it may not be. I intentionally set up my projects such that tox is
appropriate for upstream CI, not distribution package ch
On Mon, Jan 13, 2020 at 12:20:15PM +0100, Miroslav Suchý wrote:
> Dne 10. 01. 20 v 18:21 Iñaki Ucar napsal(a):
> > Most of the time, I end up copying the spec changelog in the commit
> > message and I don't change the update template,
>
> +1
> Thou, occasionaly I *delete* some of those commits as
On Sun, 2020-01-12 at 23:24 +0100, Miro Hrončok wrote:
>
> > Please don't mention it as required or even necessarily recommended, as
> > it may not be. I intentionally set up my projects such that tox is
> > appropriate for upstream CI, not distribution package checking, and
> > intend distributio
On Fri, Jan 10, 2020 at 9:37 AM Pierre-Yves Chibon wrote:
> Thus our call for input to accept or reject the idea and if the former
> scope/define the system.
Whatever you decide, please try it out on a small set of packages that
you personally maintain for a long time. This "field testing" will
e
On Mon, 13 Jan 2020 at 15:23, Joe Doss wrote:
>
> On 1/12/20 3:19 PM, Marius Schwarz wrote:
> > Am 10.01.20 um 17:36 schrieb Pierre-Yves Chibon:
> >> Good Morning Everyone,
> >>
> >> This is not a new idea, it has been presented at flock last year and
> spoken
> >> about on this very list this fal
On 1/13/20 2:47 PM, Neal Gompa wrote:
changelogs often include CVE information, especially useful when the
fixes are backported rather than included as part of the regular
update/release process.
How could the CVE info be available in the absence of changelogs?
In Fedora, this information has
On Monday, 13 January 2020 12:26:36 CET Miro Hrončok wrote:
> golang-github-codahale-aesnicheck go-sig, orphan3 weeks
> ago
We have no consumer for this library anymore, it was a dependency for caddy
(https://bugzilla.redhat.com/show_bug.cgi?id=1488739) which was dropped in
Fe
On 1/12/20 3:19 PM, Marius Schwarz wrote:
> Am 10.01.20 um 17:36 schrieb Pierre-Yves Chibon:
>> Good Morning Everyone,
>>
>> This is not a new idea, it has been presented at flock last year and
spoken
>> about on this very list this fall, so I'd like to push it a little
further.
>>
>> Do we want to
On Mon, Jan 13, 2020 at 2:02 PM Przemek Klosowski via devel
wrote:
>
> On 1/10/20 8:14 PM, Michael Catanzaro wrote:
> > On Fri, Jan 10, 2020 at 9:46 pm, Richard W.M. Jones
> > wrote:
> >> OpenSUSE proved years and years ago that dropping %changelog is
> >> possible, easy and desirable. We should
On Mon, Jan 13, 2020 at 7:24 PM Silvia Sánchez wrote:
>
>
> Hello Harsh,
>
> Turned out you're right, Pantheon is written from scratch as it is explained
> in this link: https://wiki.archlinux.org/index.php/Pantheon
> No, your information wasn't wrong, I was confused. Sorry about that.
Hi,
so
On 1/10/20 8:14 PM, Michael Catanzaro wrote:
On Fri, Jan 10, 2020 at 9:46 pm, Richard W.M. Jones
wrote:
OpenSUSE proved years and years ago that dropping %changelog is
possible, easy and desirable. We should do that IMHO.
They still have %changelog at the bottom of each spec file, but as the
On Mon, Jan 13, 2020 at 12:52 PM Brian (bex) Exelbierd
wrote:
>
> On Mon, Jan 13, 2020 at 3:38 AM Neal Gompa wrote:
>>
>> On Sun, Jan 12, 2020 at 9:16 PM Chris Murphy wrote:
>> >
>> > Hi,
>> >
>> > This might be a bad idea. But I'm looking for better ideas than status quo.
>> >
>> > A known prob
=
#fedora-meeting-1: FESCO (2020-01-13)
=
Meeting started by contyk at 14:59:55 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-01-13/fesco.2020-01-13-14.59.log.html
Meeting summary
Hello Harsh,
Turned out you're right, Pantheon is written from scratch as it is
explained in this link: https://wiki.archlinux.org/index.php/Pantheon
No, your information wasn't wrong, I was confused. Sorry about that.
Kind regards,
Silvia
FAS: Lailah
On Mon, 13 Jan 2020 at 20:04, Harsh Ja
On Mon, Jan 13, 2020 at 3:38 AM Neal Gompa wrote:
> On Sun, Jan 12, 2020 at 9:16 PM Chris Murphy
> wrote:
> >
> > Hi,
> >
> > This might be a bad idea. But I'm looking for better ideas than status
> quo.
> >
> > A known problem is upgraded systems get crusty over time. Maybe folks
> should clean
On Mon, 2020-01-13 at 10:52 +0100, Florian Weimer wrote:
> * Kevin Fenzi:
>
> > Can packages built in this buildroot be used on the same system with
> > packages from the normal buildroot?
>
> Yes, I expect them to be compatible at the interface level because the
> flags do not directly alter cal
Hey ,thanks for the reply .
About the dm , pantheon should use lightdm and as you said it probably
isn't marked to be installed or if it is , it isn't configured properly .
I have not tried to start a graphical session form tty though I can login
just fine .
On the topic of gnome , i thought panthe
Hi, all,
This topic goes along the lines of Matthew’s Operating System Factory
discussion[1], but with a slightly different angle. It also is the
generalization of the Change we have proposed recently [2]
So let me start with the problem:
In Fedora now we have a well known and established proces
On Sun, Jan 12, 2020 at 4:49 PM Hans Ulrich Niedermann
wrote:
> On Thu, 09 Jan 2020 16:51:36 +0100
> Nicolas Mailhot via devel wrote:
>
> > Le 2020-01-09 15:02, Stephen John Smoogen a écrit :
> >
> > > I have seen something like this happen in the past. I think it was
> > > around Fedora 18? ker
On Sun, Jan 12, 2020 at 5:46 PM Bohdan Khomutskyi
wrote:
> Hello,
>
> I posted more benchmark results in this article:
> https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS
>
> In short, bigger block size and higher compression ratio does not increase
> the installation time for Fedo
On Mon, Jan 13, 2020 at 12:34:15PM +0100, Miro Hrončok wrote:
> qpid-proton is orphaned with a lot of impacted packages:
...snip...
>
> This section is not very accurate. It is not Koji that gets broken, only
> python3-koji-hub-plugins and the dependent packages just need koji, not the
> kojihub p
On Mon, Jan 13, 2020 at 10:52:32AM +0100, Florian Weimer wrote:
> * Kevin Fenzi:
>
> > Can packages built in this buildroot be used on the same system with
> > packages from the normal buildroot?
>
> Yes, I expect them to be compatible at the interface level because the
> flags do not directly al
No missing expected images.
Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 4/155 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-Rawhide-20200112.n
On Monday, January 13, 2020 4:07:56 PM CET Chris Murphy wrote:
> I understand the path of least resistance with upgrades. They're
> better off being upgraded, even if they silently have sale bits no
> longer upgraded. From a security perspective, I think being silent
> about that is not great.
Bei
Le 2020-01-13 16:20, Randy Barlow a écrit :
Now, we could change the policy too to get around this, but I think
"git tag" is a natural way for me to indicate "I want to build and
release this commit to this Fedora release".
Please do not try to infer packaged commit from src.fedoraproject.org
OLD: Fedora-Rawhide-20200112.n.0
NEW: Fedora-Rawhide-20200113.n.0
= SUMMARY =
Added images:1
Dropped images: 0
Added packages: 8
Dropped packages:4
Upgraded packages: 36
Downgraded packages: 0
Size of added packages: 725.35 KiB
Size of dropped packages
On Sat, 2020-01-11 at 11:19 -0600, Martin Jackson wrote:
> I don't know if things like pipx exist for other scripting
> languages, but do other people think that's worth exploring?
> (Currently pipx uses tox in what seems like a weird way, and we'd
> need to package userpath and tox-venv to make th
On Mon, 2020-01-13 at 12:28 +0100, Pierre-Yves Chibon wrote:
> If I tag foo 1.0 with a first changelog entry, then koji builds 1.0-1
> with that changelog.
I think it would be better if the release were part of the git tag,
instead of automatically generating it. Not all packages use an integer
f
On Mon, Jan 13, 2020 at 5:53 AM Neal Gompa wrote:
>
> On Mon, Jan 13, 2020 at 12:00 AM Chris Murphy wrote:
> >
> > On Sun, Jan 12, 2020 at 9:39 PM Kevin Fenzi wrote:
> > >
> > > On Sun, Jan 12, 2020 at 07:15:39PM -0700, Chris Murphy wrote:
> > > > Hi,
> > > >
> > > > This might be a bad idea. Bu
On 01/13/2020 06:20 AM, Vít Ondruch wrote:
>
> Dne 11. 01. 20 v 5:46 Tom Stellard napsal(a):
>> On 01/08/2020 11:28 PM, Miro Hrončok wrote:
>>> On 08. 01. 20 23:47, Tom Stellard wrote:
I suspect that if I can find some way to set the CC and CXX environment
variables for all builds, not j
On Mon, Jan 13, 2020 at 1:22 AM Kamil Dudka wrote:
>
> On Monday, January 13, 2020 5:59:49 AM CET Chris Murphy wrote:
> > On Sun, Jan 12, 2020 at 9:39 PM Kevin Fenzi wrote:
> >
> > >
> > >
> > > On Sun, Jan 12, 2020 at 07:15:39PM -0700, Chris Murphy wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > >
On Mon, Jan 13, 2020 at 08:19:36AM -0600, Richard Shaw wrote:
>Just catching up on this thread...
>How about an incremental step? (I don't know how difficult it would be to
>implement however)...
This is what Vit was suggesting which seems like a very nice idea :)
>What about sepa
On Mon, Jan 13, 2020 at 09:30:33AM -0500, Randy Barlow wrote:
> On Fri, 2020-01-10 at 14:37 +0100, Pierre-Yves Chibon wrote:
> > For historical reasons, bodhi treats the "greenwave_failed" status as
> > "passed", so it will not gate updates if greenwave failed to give it
> > a go/nogo answer.
>
>
On Fri, 2020-01-10 at 14:37 +0100, Pierre-Yves Chibon wrote:
> For historical reasons, bodhi treats the "greenwave_failed" status as
> "passed", so it will not gate updates if greenwave failed to give it
> a go/nogo answer.
It's not historical, or we wouldn't be discussing this - the message
means
Dne 11. 01. 20 v 5:46 Tom Stellard napsal(a):
> On 01/08/2020 11:28 PM, Miro Hrončok wrote:
>> On 08. 01. 20 23:47, Tom Stellard wrote:
>>> I suspect that if I can find some way to set the CC and CXX environment
>>> variables for all builds, not just ones using autoconf, cmake or meson,
>>> that m
Just catching up on this thread...
How about an incremental step? (I don't know how difficult it would be to
implement however)...
What about separating the change log to a separate file in dist-git?
Something like the traditional "ChangeLog"?
I like to keep my spec files in sync between release
On Mon, Jan 13, 2020 at 11:28:41AM +0100, Miroslav Suchý wrote:
> Dne 13. 01. 20 v 10:46 Petr Pisar napsal(a):
> > No, it won't as we have competing %{version}-%{release} strings among
> > multiple
> > packages. E.g. perl source bundles an Encode module. And we know the module
> > is updated frequ
Am 13.01.20 um 14:05 schrieb Vít Ondruch:
> While I like the annotated tag proposal, I would really appreciate if
> the first step was replacing the:
(..:)
> %changelog
>
> %include changelog
>
> ~~~
>
> where the `changelog` file would be either available with the original
> changelog content
On Mon, Jan 13, 2020 at 8:07 AM Panu Matilainen wrote:
>
> On 1/13/20 2:44 PM, Nicolas Mailhot via devel wrote:
> > Le 2020-01-13 12:52, Florian Weimer a écrit :
> >
> >> I have trouble matching this claim to my experience working on
> >> redhat-rpm-config. Why is it painful to use Git as it was
Dne 13. 01. 20 v 14:05 Vít Ondruch napsal(a):
> Dne 12. 01. 20 v 22:56 Miro Hrončok napsal(a):
>> On 10. 01. 20 17:36, Pierre-Yves Chibon wrote:
>>> Is there a different approach, e.g. by using towncrier[1] or something
>>> comparable, to track changes outside the spec file?
>> Is the idea of usin
On 1/13/20 2:44 PM, Nicolas Mailhot via devel wrote:
Le 2020-01-13 12:52, Florian Weimer a écrit :
I have trouble matching this claim to my experience working on
redhat-rpm-config. Why is it painful to use Git as it was designed?
Because redhat-rpm-config is not "using Git as it was designed
Dne 12. 01. 20 v 22:56 Miro Hrončok napsal(a):
> On 10. 01. 20 17:36, Pierre-Yves Chibon wrote:
>> Is there a different approach, e.g. by using towncrier[1] or something
>> comparable, to track changes outside the spec file?
>
> Is the idea of using annotated git tags abandoned altogether?
>
> We
Hi,
not sure which mailing list to point for asking, but I've an issue while
building unboundid-ldapsdk for el8 in copr.
When trying to build I get dnf error:
DEBUG util.py:596: No matches found for the following disable plugin
patterns: local, spacewalk
DEBUG util.py:598: Copr repository
46 kB/
On Mon, Jan 13, 2020 at 12:00 AM Chris Murphy wrote:
>
> On Sun, Jan 12, 2020 at 9:39 PM Kevin Fenzi wrote:
> >
> > On Sun, Jan 12, 2020 at 07:15:39PM -0700, Chris Murphy wrote:
> > > Hi,
> > >
> > > This might be a bad idea. But I'm looking for better ideas than status
> > > quo.
> > >
> > > A
Hello,
Pantheon relies heavily on Gnome, so installing Gnome Session in a Pantheon
desktop makes sense. About the DM, not sure. LightDM is not Pantheon DM,
because Pantheon doesn't have a DM of its own AFAIK. I'm guessing, because
I don't use Pantheon, that what happens is that when Pantheon is
Le 2020-01-13 12:52, Florian Weimer a écrit :
I have trouble matching this claim to my experience working on
redhat-rpm-config. Why is it painful to use Git as it was designed?
Because redhat-rpm-config is not "using Git as it was designed". It’s
using git as a centralized flat and linear SC
Dne 11. 01. 20 v 4:14 Neal Gompa napsal(a):
> On Fri, Jan 10, 2020 at 12:52 PM Vít Ondruch wrote:
>>
>> Dne 10. 01. 20 v 18:33 Fabio Valentini napsal(a):
>>
>> On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon wrote:
>>> Good Morning Everyone,
>>>
>>> This is not a new idea, it has been presented a
* Nicolas Mailhot via devel:
> Le vendredi 10 janvier 2020 à 17:36 +0100, Pierre-Yves Chibon a écrit :
>> Good Morning Everyone,
>>
>> This is not a new idea, it has been presented at flock last year and
>> spoken
>> about on this very list this fall, so I'd like to push it a little
>> further.
>
On 13. 01. 20 12:40, Jun Aruga wrote:
When removing the changelog in a spec file, users (not package
maintainers) using this command are disappointed?
```
$ rpm -q --changelog python3
* Tue Oct 15 2019 Miro Hrončok - 3.7.5-1
- Update to 3.7.5
...
```
No, this would still work. It would be inj
On 13. 01. 20 12:28, Pierre-Yves Chibon wrote:
On Sun, Jan 12, 2020 at 10:56:00PM +0100, Miro Hrončok wrote:
On 10. 01. 20 17:36, Pierre-Yves Chibon wrote:
Is there a different approach, e.g. by using towncrier[1] or something
comparable, to track changes outside the spec file?
Is the idea of
When removing the changelog in a spec file, users (not package
maintainers) using this command are disappointed?
```
$ rpm -q --changelog python3
* Tue Oct 15 2019 Miro Hrončok - 3.7.5-1
- Update to 3.7.5
...
```
--
Jun | He - His - Him
___
devel mail
qpid-proton is orphaned with a lot of impacted packages:
Depending on: qpid-proton (24), status change: 2019-12-20 (3 weeks ago)
...
koji (maintained by: ausil, bowlofeggs, kevin, mikem, puiterwijk)
python3-koji-hub-plugins-1.19.1-2.fc32.noarch requires
python3-qpid-proton =
Le 2020-01-13 12:07, Pierre-Yves Chibon a écrit :
Hi,
I don't quite see how it conflicts with it either.
You may end up having foo-1.0-42 in copr and foo-1.0-32 in koji which
would lead
to a foo-1.0-32 (or -39) at the next build, but I'm not seeing how it's
a
problem per say.
Correct handl
On Sun, Jan 12, 2020 at 10:56:00PM +0100, Miro Hrončok wrote:
> On 10. 01. 20 17:36, Pierre-Yves Chibon wrote:
> > Is there a different approach, e.g. by using towncrier[1] or something
> > comparable, to track changes outside the spec file?
>
> Is the idea of using annotated git tags abandoned al
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If
Dne 10. 01. 20 v 18:21 Iñaki Ucar napsal(a):
> Most of the time, I end up copying the spec changelog in the commit
> message and I don't change the update template,
+1
Thou, occasionaly I *delete* some of those commits as they are unnessary in
changelog. E.g.:
* typo fix
* revert of
* prev
On Fri, Jan 10, 2020 at 09:18:35PM +0100, Nicolas Mailhot via devel wrote:
> Le vendredi 10 janvier 2020 à 20:53 +0100, Fabio Valentini a écrit :
> >
> > You can never expect our tooling to do "magic" (TM) and work "just
> > right", no matter which Versions and Releases and Epochs of packages
> >
Le 2020-01-13 11:28, Miroslav Suchý a écrit :
Dne 13. 01. 20 v 10:46 Petr Pisar napsal(a):
No, it won't as we have competing %{version}-%{release} strings among
multiple
packages. E.g. perl source bundles an Encode module. And we know the
module
is updated frequenly on CPAN. Thus we build perl-
Dne 13. 01. 20 v 10:46 Petr Pisar napsal(a):
> No, it won't as we have competing %{version}-%{release} strings among multiple
> packages. E.g. perl source bundles an Encode module. And we know the module
> is updated frequenly on CPAN. Thus we build perl-Encode-V1-R1 from perl.spec,
> then we build
Le 2020-01-13 11:01, Panu Matilainen a écrit :
You keep saying that, but maybe you were not involved with
redhat-rpm-config back when it was that way. It was the most hideous
piece of package I had ever worked with, because the model of external
tarballs is just absurd and does not work at all w
On 1/10/20 7:35 PM, Nicolas Mailhot via devel wrote:
Dropping changelog is easy. Since we have a clean separation of spec
repo (src.fedoraproject.org) and project repo (pagure, gitlab or
elsewhere) the spec should just be assembled from all the
src.fedoraproject.org commit messages not present i
* Kevin Fenzi:
> Can packages built in this buildroot be used on the same system with
> packages from the normal buildroot?
Yes, I expect them to be compatible at the interface level because the
flags do not directly alter calling conventions. There could be a
slowdown mixing package versions, t
On Fri, Jan 10, 2020 at 10:14:39PM -0500, Neal Gompa wrote:
> On Fri, Jan 10, 2020 at 12:52 PM Vít Ondruch wrote:
> > Dne 10. 01. 20 v 18:33 Fabio Valentini napsal(a):
> > > What about "number of commits since last version update" (possibly
> > > tagged in git)? That should encompass the possibili
On Fri, Jan 10, 2020 at 05:36:46PM +0100, Pierre-Yves Chibon wrote:
>
> The release field would need to be set by koji ignoring whatever is in the
> spec file. How do we want to do this?
> - Based on dates?
> - Using an always increasing integer?
> - Using the number of successful builds sin
On 1/12/20 9:38 AM, Luya Tshimbalanga wrote:
The challenge about upstream is when they lack activity for years and
contributions are very difficult when users lack knowledge of coding
without proper guidance. For example, attempting to improve say
CellWriter (sorely missing due to the lack of
On Monday, January 13, 2020 5:59:49 AM CET Chris Murphy wrote:
> On Sun, Jan 12, 2020 at 9:39 PM Kevin Fenzi wrote:
>
> >
> >
> > On Sun, Jan 12, 2020 at 07:15:39PM -0700, Chris Murphy wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > This might be a bad idea. But I'm looking for better ideas than st
71 matches
Mail list logo
