Dne 22.3.2017 v 11:00 Nikos Mavrogiannopoulos napsal(a):
> Hi,
> For several packages it is possible to automate build, test and
> package updating on multiple fedora releases (+epel) in a single
> keypress using the cockpituous (sic) tools [0]. These tools hide quirks
> and requirements of the fe
Dne 15.3.2017 v 04:14 Zbigniew Jędrzejewski-Szmek napsal(a):
> This conflict should be temporary, the patch to make the abrt
> handler non-exclusive should be trivial.)
Patches are welcome.
> 4. run a python script that throws an exception
>e.g. python3
> /usr/lib/python3.5/site-pack
Dne 25.2.2017 v 17:04 Michael Catanzaro napsal(a):
> I'm wondering if ABRT is still actively-developed since one of the main
> developers left Red Hat recently.
Yes. It is still actively developed. You are welcome to read our blog where we
post news about ABRT:
https://abrt.github.io/
> I have
Dne 2.1.2017 v 11:24 Miroslav Suchý napsal(a):
> Hmm, that is nice idea. Plugin for Mock which will print:
> * number of CPU
> * RAM + swap
> * storage size available
>
> I will try to work on that.
Done. You can expect it in next version of Mock:
https://github.com/rpm-s
Dne 20.12.2016 v 16:03 Pavel Raiskup napsal(a):
> The only thing I was able to find is version of mock in the log output.
Hmm, that is nice idea. Plugin for Mock which will print:
* number of CPU
* RAM + swap
* storage size available
I will try to work on that.
--
Miroslav Suchy, RHCA
Red Ha
Dne 1.1.2017 v 23:47 Till Maas napsal(a):
> AFAIK in Rawhide only one version is available for each package,
> therefore I suspect this does not have a real impact on Rawhide.
I have to take into account thirdparty repos (Copr, private repos...), where
things are not so straight.
However I am ope
Dne 6.12.2016 v 15:55 Michael Catanzaro napsal(a):
> The change page does mention that we're not disabling ABRT entirely, as
> ABRT already has the needed integration to get core dumps from systemd,
> thanks to Jakub and the other ABRT developers. We're only disabling the
> component of ABRT that p
Dne 6.12.2016 v 09:52 Gerd Hoffmann napsal(a):
> Hmm, isn't this as easy as abrt being able to find and analyze coredumps
> written by coredumpctl (in addition to the coredumps written by the abrt
> dumper)?
Yes, it is quite easy. But ABRT cannot do this query every second/minute/hour.
So systemd
Dne 5.12.2016 v 17:54 Jan Kurik napsal(a):
> Note that coredumpctl is intended as a developer tool, not as an
> automatic bug reporting tool nor as a replacement for ABRT.
Who is main user of Fedora? Developer (who may prefer coredumpctl) or normal
user (who may prefer bug reporting tool)?
>
>
Dne 24.11.2016 v 10:10 Gregorio . napsal(a):
> Hi all,
>
>
> I'm a newbie, so I don't know what are the steps to add a new application to
> the official repository. I'm asking this
> question because I ported Slingscold (fork of Slingshot, the Elementary OS
> application launcher) from GTK2 to
Dne 23.11.2016 v 15:09 Colin Walters napsal(a):
> All of that said, as far as I know we are still producing
> dnf based OpenStack images:
>
> https://kojipkgs.fedoraproject.org/compose//branched/Fedora-25-20161117.n.0/compose/CloudImages/x86_64/images/
>
> It might be that we're just not linking
I just wanted to download F25 Cloud image for OpenStack and was surprised that
there is none. There is just Atomic image.
But Atomic use rpm-ostree for installing packages. There is no DNF. However I
cannot find any module for rpm-ostree for
Ansible.
Am I missing something? What should I install
Dne 17.11.2016 v 19:26 Adam Williamson napsal(a):
You'll notice we don't explicitly specify *how* you should do this. That
is, if you're currently running Fedora 23, and you want to upgrade to
Fedora 25 next week, are you supposed to:
i) Upgrade to Fedora 24 first, then from Fedora 24 to Fedora
Dne 31.10.2016 v 12:55 Tom Hughes napsal(a):
> The problem, as I believe has been repeatedly explained, is that you don't
> really have any idea whether the connection
> is metered. Yes you may be trying to guess by considering things like 3G
> connections as metered but that is an extremely
> po
Dne 17.10.2016 v 06:46 Tim Flink napsal(a):
> Which brings me to the question that I'd like to get some feedback
> on: would it be preferable to store checks/tests within directories of
> existing dist-git repos or create a new namespace to store checks/tests
> and fiddle around with tooling etc.
Dne 31.8.2016 v 14:10 Charalampos Stratakis napsal(a):
> glacier-cli
Fixed. This was meant only for el6, but the %if was incorrectly constructed.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
h
Hi everybody.
Some of you noticed that Copr (and mock-1.2.19) is failing to initialize epel-*
buildroots. It errors with incorrect gpg
signature for some package.
It is my fault.
Epel configs use Centos and Epel gpg keys. In the 1.2.19 release I used just
Centos keys - even for the Epel repositor
I had the talk [1] about Fedora Sponsorship process at Flock. And we had
very interesting follow-up discussion.
We come up with several improvements, which should be easy to implement
and may improve the process a lot. I am posting it here so more people
can see that and join the discussion.
Dne 13.7.2016 v 21:15 Avram Lubkin napsal(a):
> Does anyone have any preferences, thoughts or alternative approaches?
I do not have the solution. But I want to point out similar case, which I
recently reported against pyp2rpm:
https://github.com/fedora-python/pyp2rpm/issues/63
--
Miroslav Suc
Dne 20.6.2016 v 15:14 Karsten Hopp napsal(a):
>
> Copy doesn't allow multiple builds with the same N-V-R either according to
> this:
> https://fedorahosted.org/copr/wiki/UserDocs#WhathappenswhenItrytobuildapackagewiththesameversionnumber
Yes. But you can have the same NEVRA in different project
Dne 20.6.2016 v 14:18 Karsten Hopp napsal(a):
> Does anyone have any other ideas for this problem ?
Rebuild it in Copr?
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/
Dne 15.6.2016 v 10:14 Ade napsal(a):
> Why is this? Well some time ago the behaviour of the tool changed and now
> the only way to proceed is to click in
> "Restart and Install" and this is NEVER what I want to do. I never want to
> reboot my desktop just to apply updates, Id
> rather apply all
Hi,
I started rebuilds of whole rubygems.org as RPM packages in Copr.
See:
https://copr.fedorainfracloud.org/coprs/g/rubygems/rubygems/
However lots of gems cannot be imported due licensing problems.
Such gems fail with this dist-git log:
http://copr-dist-git.fedorainfracloud.org/per-task-logs
Dne 28.5.2016 v 05:11 Ben Rosser napsal(a):
> I agree; just because the change happened upstream in systemd doesn't mean
> that this shouldn't be evaluated in Fedora
> itself before being turned on by default.
>
> This absolutely seems like the kind of thing that should be a system-wide
> change
Dne 19.5.2016 v 10:35 Vít Ondruch napsal(a):
> Do I understand correctly that you build just the latest version of each
> package?
Yes.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fed
Dne 19.5.2016 v 14:59 Stephen John Smoogen napsal(a):
> That isn't why he is doing this. I don't think he is looking to get
> 15,000 packages added to Fedora. He is just making sure that if you
> need that poorly written python software... it is still in an rpm
> somewhere.
Yes. This is not inten
Dne 12.5.2016 v 17:51 Mike Chambers napsal(a):
> Hell, if really want to make it simple, why not just /etc/repos.d?
+1
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/ad
Dne 9.5.2016 v 14:43 M.Hanny Sabbagh napsal(a):
> So what can I do furthermore about this?
> Thanks.
Although it can be painful for you, there is pretty high chance that it is not
priority for developer. Especially if it
cannot be reproduced on his own hardware.
Being pushy to maintainer is very
Hi,
due to a bug in Copr code some projects shared a GPG key with some other Copr
project.
We informed the owners of those projects and we resigned all packages in those
projects
by new GPG key.
These projects were affected by one bug [1]:
@pdc/pdc-test
nb/keepassx
And these by another bug [2]
Dne 5.5.2016 v 06:07 Miroslav Suchý napsal(a):
> There will be an outage starting at 2016-05-05 08:00 UTC, which will
> last approximately 6 hours.
The outage is over now.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
There will be an outage starting at 2016-05-05 08:00 UTC, which will
last approximately 6 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2016-05-05 08:00 UTC'
Reason for outage: Upgrade all copr packages to newer ve
Dne 20.4.2016 v 23:18 Miroslav Suchy napsal(a):
> We have temporary problems with ppc builders so I stopped ppc builds for
> now.
> This does not affect i386 and x86_64 queue.
> I anticipate that tomorrow I may start it again.
PPC builders works again.
--
Miroslav Suchy, RHCA
Red Hat, Senior So
Dne 18.4.2016 v 22:01 Robert Mayr napsal(a):
> 'm trying to build a package in COPR, the source RPM is rather large (500MB),
> but it always worked fine also with bigger
> source files. I supposed I had a bad URL an uploaded the SRPM twice, but the
> result is the same.
I added there more space.
I am very sorry.
Today Lubos K. accidentally submitted 10k packages to Copr. I wanted to run one
simple SQL query to set all those builds
as failed. Unfortunately I made big mistake - I forgot to add one column to
'where' condition. As result of this error
*all* builds were marked as failed. All
Dne 8.4.2016 v 04:03 Ralf Corsepius napsal(a):
> Has this change and the mapping which buildroot uses dnf rsp. yum been
> reflected to the mock packages [1]?
Yes. Mock used DNF for rawhide for ages to test this setup before it landed in
Koji and we have been waiting for
necessary code change in
Dne 14.3.2016 v 02:06 Neal Gompa napsal(a):
> DNF can totally process conditional dependencies as libsolv in Fedora
> is compiled with support for it. I'm not sure why Koschei isn't
> handling it well.
Maybe because Koschei builds using mock (?) and mock by default still use yum
(but rawhide) and
Dne 4.3.2016 v 23:36 Zbigniew Jędrzejewski-Szmek napsal(a):
> I finally pushed the split of the systemd package to Rawhide and F24 today
> [https://fedoraproject.org/w/index.php?title=Changes/systemd_package_split].
> If you upgrade with dnf you should see something like this:
> Installing:
> syst
Hi,
I just added
fedora-24-x86_64
fedora-24-i386
chroots to Copr. I automatically enabled those chroots for every project, which
has fedora-rawhide-* enabled. And I
copied all build artifact from rawhide to fedora-24-* repository.
Ppc64le repositories are not available yet. I will enable it a
Dne 26.2.2016 v 11:20 Carlos O'Donell napsal(a):
> No languages are available by default, we did this because otherwise
> you keep carrying forward locales that you can't remove.
For this reasons we have weak dependencies. I guess that:
Recommends: glibc-all-langpacks
can do the work (install or
Dne 9.2.2016 v 10:13 Miroslav Suchy napsal(a):
> There will be an outage starting at 2016-02-11 08:00 UTC, which will
> last approximately 1 hour.
The outage is over.
There were some failed builds due misconfigured dist-git and signing server
just after the provision.
Please resubmit such failed
Dne 9.2.2016 v 10:13 Miroslav Suchy napsal(a):
> There will be an outage starting at 2016-02-11 08:00 UTC, which will
> last approximately 1 hour.
The outage is over.
There were some failed builds due misconfigured dist-git and signing server
just after the provision.
Please resubmit such failed
Dne 10.2.2016 v 07:19 Eric Griffith napsal(a):
> Functionally, whats the effect of this change?
If someone has
Requires: /bin/sed
It will stop working.
Just the dependency. The call in shell will still work.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-bu
Dne 3.2.2016 v 23:28 Felix Miata napsal(a):
> Problem #1:
> NAICT, DNF, like Yum before it, offers no option I can recognize from its man
> page to download less than all the to-be-updated/installed packages before
> proceeding to install any packages. Thus it downloads (typically hundreds of
> pac
Dne 2.2.2016 v 23:20 Christian Stadelmann napsal(a):
> Are there any plans to make dnf work with those? Or do I have to edit repo
> files for that? `dnf copr enable` could use these GPG keys if it could make
> sure this package is installed.
Good idea. But one step in time. I hesitate to change
Dne 29.1.2016 v 19:51 Matthew Miller napsal(a):
> I'd like to let go of ownership of the package, and unless someone else
> really wants to invest time into it, I think retiring it completely is
> the way to go.
I still use this program. And it has no glitches on 32 arch. Until there is new
open
Planned Outage: Copr upgrade - 2016-01-19 20:00 UTC
There will be an outage starting at 2016-01-19 20:00 UTC, which will last
approximately 1 hours.
During the outage backend will stop processing new task and they will be queued
in frontend and processed just after the
outage.
To convert UTC
Dne 13.1.2016 v 17:41 Greg Hellings napsal(a):
> I've been trying to reach jstribny(
> https://admin.fedoraproject.org/accounts/user/view/jstribny) for a few
> weeks regarding commit privileges on EPEL7 to several packages in
> pkgdb. Most notable among those are:
> rubygem-minitest
> rubygem-i18n
Dne 9.12.2015 v 17:06 Miroslav Suchý napsal(a):
> Planned Outage: Copr upgrade - 2016-01-04 08:00 UTC
>
> There will be an outage starting at 2016-01-04 08:00 UTC, which will last
> approximately 4 hours.
>
> To convert UTC to your local time, take a look at
> http://f
Dne 13.12.2015 v 05:58 Christopher napsal(a):
> Which components/packages are best candidates for adding a feature which
> would make it easier for users to track
> changes from the default %config %files on the system?
... [SNIP] ...
> rpmconf is nice, because it helps me easily compare configura
Planned Outage: Copr upgrade - 2016-01-04 08:00 UTC
There will be an outage starting at 2016-01-04 08:00 UTC, which will last
approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '-MM-DD HH:MM UTC'
R
Dne 4.12.2015 v 08:25 James Hogarth napsal(a):
> The question on my mind is how useful is that when you reach that number of
> things blocking it? Who in their right mind
> is going to check one of the thousand or so packages marked blocking that as
> a place to start packaging? That's not even
>
Dne 26.11.2015 v 12:08 Miroslav Suchý napsal(a):
> Planned Outage: Copr upgrade - 2015-11-30 08:00 UTC
>
> There will be an outage starting at 2015-11-30 08:00 UTC, which will last
> approximately 4 hours.
This outage have been cancelled. I hit some obstacles in staging environm
Planned Outage: Copr upgrade - 2015-11-30 08:00 UTC
There will be an outage starting at 2015-11-30 08:00 UTC, which will last
approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '-MM-DD HH:MM UTC'
R
Dne 17.11.2015 v 02:39 Stephen Gallagher napsal(a):
> b'dnf-plugins-core': 117
Nice to have, however Minimal installation can live without it.
> b'plymouth-scripts': 121
> b'plymouth': 121
This really does not need to be on minimal installation.
And you can save a lot of data if you purge locale
Dne 13.11.2015 v 13:30 David Timms napsal(a):
> Hi, I submitted an audacity build f22,23,rawhide. Usually it finishes in
> 12-20 mins. 22/23 are done, but rawhide's been 80 minutes, so I think
> something has gone wrong... No logs yet for it.
>
> https://copr.fedoraproject.org/coprs/dtimms/audacit
Dne 12.11.2015 v 14:36 Dave Johansen napsal(a):
> https://copr.fedoraproject.org/coprs/daveisfera/odb_2.5/build/138953/
>
> In the above COPR, it says the x86_64 for rawhide failed, but the logs look
> fine and the .rpm results are there, so am I
> missing something or is this a false failure?
I
Dne 26.10.2015 v 18:39 Zbigniew Jędrzejewski-Szmek napsal(a):
> --distro-sync is now (in git, I don't think this version was released yet)
> the default in dnf-plugin-system-upgrade.
OK. So I will file BZs for all issues I find with --distro-sync I hit.
>> # dnf system-upgrade download --releasev
I am trying to upgrade to F23 (I know still not finished but...)
In past I always done 'distro-sync'. Albeit with yum.
Now I tried:
dnf system-upgrade download --releasever=23 --distro-sync
dnf system-upgrade download --releasever=23 --distro-sync --best
dnf system-upgrade download --releas
Dne 19.10.2015 v 12:53 Marek Skalický napsal(a):
> Hello everyone,
> does someone know how the "Request new package" in pkgdb works?
> (https://fedoraproject.org/wiki/PackageDB_admin_requests )- for 6 days I
> have status of this request "Approved", but I can't do fedpkg clone...
> What is wrong? W
Dne 17.10.2015 v 23:55 Dave Johansen napsal(a):
> How can I do a variable expansion that doesn't have - before and after? I
> tried "slc${releasever}X" [1] and
> "slc$releaseverX" [2] but neither worked.
> Thanks,
> Dave
>
> [1]:
> https://copr-be.cloud.fedoraproject.org/results/daveisfera/odb_2
Dne 16.10.2015 v 10:13 Alexander Ploumistos napsal(a):
> Btw, what about upstream links to the keys in the spec file?
I did not use SourceX in spec file, because my source is tar.gz file created
from github.
This make the maintenance more easier.
However - good idea - I will create some documenta
Dne 15.10.2015 v 23:23 Alexander Ploumistos napsal(a):
> Hello,
>
> Please forgive my ignorance, but how is this supposed to be used? I
> guess it's handy to keep track of all the current keys, but unlike,
> say rpmfusion-free-release, the keys are not placed or linked in
> /etc/pki/, nor are they
Dne 15.10.2015 v 16:24 Michael Cronenworth napsal(a):
> I would suggest adding PlayOnLinux to RPMFusion. Downloading binaries this
> way was frowned[1] upon before.
>
> [1] https://fedorahosted.org/fesco/ticket/1331
However POL does not download the games. And as stated before it is useful for
Dne 15.10.2015 v 18:27 Pierre-Yves Chibon napsal(a):
> On Thu, Oct 15, 2015 at 11:59:56AM -0400, Bastien Nocera wrote:
>>
>>
>> - Original Message -
>>> It is my pleasure to announce new version of Copr.
>>> https://copr.fedoraproject.org/
>>
>> Seems that the new version broke sorting by
Dne 15.10.2015 v 14:43 Stephen Gallagher napsal(a):
>> If you have some personal project and you want to change it to
>> > group project, then please let me know and we change it manually.
> Question: if we convert COPRs like this, is there any mechanism in
> place to forward requests from the old
Dne 15.10.2015 v 15:46 Pete Travis napsal(a):
> The greater feasibility question IMO is whether it is even possible for
> PlayOnLinux to be effective when using system wine, and if not, whether
> the package can be built in a guidelines-compliant way when it bundles
> and patches this way. Jirka,
It is my pleasure to announce new version of Copr.
https://copr.fedoraproject.org/
What's new? Group projects!
When you log in. You can see in right column link "My Groups". There you can
see list of your FAS groups and you can
activate them. In fact, you actually create alias for them. E.g. F
Dne 14.10.2015 v 16:50 Bastien Nocera napsal(a):
> If the application cannot work without downloading anything, or being supplied
> third-party (sometimes proprietary) applications, then it's closer to an
> emulator than a front-end that's generally useful.
The guidelines speaks about *dependencie
Dne 14.10.2015 v 04:21 Dusty Mabe napsal(a):
> Obviously it would be nice
> if ansible went to python3 but I think they have stated clearly that
> they are sticking with python2 for backwards compat with systems that
> still need 2.4.
*nod*
https://github.com/ansible/ansible/issues/1409
--
Miros
Tracked under:
https://bugzilla.redhat.com/show_bug.cgi?id=1268883
What we know so far is:
* it happen under F23
* it works in F22
* it works with dnf
* it does not work with yum.
So "mock --dnf" can be used as temporary workaround for those who are blocked
by this.
--
Miroslav Suchy, RHCA
Dne 30.9.2015 v 00:17 Cole Robinson napsal(a):
> I'm hitting scriplet errors when trying to build f23 qemu in mock on an up to
> date f23 host. Example:
>
> $ mock --root fedora-23-x86_64 --init
> ...
> $ mock --root fedora-23-x86_64 --rebuild qemu-2.4.0-4.fc23.src.rpm
> ...
>
> Transaction Summa
Dne 10.9.2015 v 15:53 Stephen Gallagher napsal(a):
> If they can't get
> that software from Fedora, they *will* get it from another source (or
> use a different OS that doesn't get in their way).
Sadly true.
Therefore +1 from me to record the positive feedback.
I have one example in my head [1] w
Dne 2.9.2015 v 20:59 Brendan Conoboy napsal(a):
> 5. Ring membership is at the source package level, not the binary
> package. If one source package's binary/noarch sub-package is in ring
> 0, all sub-packages are in ring 0.
So we are going to include all those *-doc subpackages? And all language
Dne 3.9.2015 v 00:16 janlukasgern...@freenet.de napsal(a):
> repo is now available here.
I assume this one:
https://copr.fedoraproject.org/coprs/jeanluc/FeedReader/
:)
It looks good. Although the spec from Pete looks little bit better. You may
want to add yourself to CC of
https://bugzilla.red
Dne 1.9.2015 v 22:00 janlukasgern...@freenet.de napsal(a):
> I was advised to ask on this list for help regarding setting up a copr
> repository.
> I just released verion 1.2 of my application "FeedReader":
> http://jangernert.github.io/feedreader/
> "FeedReader is a modern desktop application des
Dne 20.8.2015 v 13:42 Michael Schwendt napsal(a):
> Your script output does not tell anything at all about activity of all
> packagers in the package collection, in the normal review queue(s), in
> pkgdb. No clues about number of orphaned/retired packages. No clues about
> semi-dead packages where
Dne 21.8.2015 v 00:58 Orion Poplawski napsal(a):
> My gut reaction to this is, my god, we don't need *more* packages in Fedora,
> we need more people maintaining the pile we already have. So I'd like to see
> more packagers added as co-maintainers of packages.
Hmm,
so does it means that "becoming
Dne 20.8.2015 v 08:57 Ralf Corsepius napsal(a):
> 5. You cannot push around sponsors.
> The ability to sponsor packagers is a privilege and not a duty. It's not
> going to fly to make a volunteer privilege a
> burdon.
I repeated several times in this thread that it is perfectly fine when there is
Dne 17.8.2015 v 18:30 Michael Schwendt napsal(a):
> Have you followed the How To Get Sponsored guidelines?
...
> So what?
>
> I'm tired by such an attitude and by all complainers, who sit and wait
> instead of showing a bit of activity and following the guidelines.
Your attitude just discouraged
BTW this report reveals that we have just 39 active sponsors (during past year).
If you are sponsors, please consider sponsoring somebody from the queue:
http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html
Good start is to take some bug from top (or bottom) of
http://red.ht/1K3njkO
y sponsored: [u'jehane', u'fbo', u'tdecacqu']
Mikolaj Izdebski - directly sponsored: [u'mikedep333', u'stbenjam',
u'am1g0', u'noa', u'vjancik', u'bjornmu',
u'jkang', u'lloesche']
Marek Ma
Dne 17.8.2015 v 16:33 Michael Schwendt napsal(a):
>> > Yes, exactly! I am waiting from March 2015.
> Waiting for what?
https://bugzilla.redhat.com/show_bug.cgi?id=1203018
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@list
Dne 17.8.2015 v 14:47 Josh Boyer napsal(a):
> I would recommend removing all of the above people from the sponsors group.
-1
There is nothing wrong on being inactive. At least as long as others are active.
If they would want, they can return any time they want.
We should *not* be like turned down
y sponsored: [u'jehane', u'fbo', u'tdecacqu']
Mikolaj Izdebski - directly sponsored: [u'mikedep333', u'stbenjam',
u'am1g0', u'noa', u'vjancik', u'bjornmu',
u'jkang', u'lloesche']
Marek Ma
Dne 15.8.2015 v 16:43 Till Maas napsal(a):
> I think the script should also consider comments to needsponsor bugs as
> sponsoring work, even if the bug was not yet assigned to someone.
Good idea, I will think about how to fetch this info.
> And
> IMHO the wording should be a little bit more frien
Dne 15.8.2015 v 20:09 Jason L Tibbitts III napsal(a):
> H> Using Bugzilla rather than FAS is not a bad idea, as some people
> H> abuse their sponsor status by blindly adding people into the packager
> H> group without any supervision. Using FAS as the information source
> H> would just hide this hi
Dne 15.8.2015 v 11:21 Christopher Meng napsal(a):
> And some people contributed a lot in the past, after this result will
> you request revoking their sponsorship and wipe them out?
NO!
There is really no pros if we revoke some sponsors. We just need them more
active. And we need more sponsors. (
ger Sponsors Group) is a good
guy - removed FE-NEEDSPONSOR from BZ
1197505
Miroslav Suchý is a good guy - worked on BZ 1061732
Miroslav Suchý is a good guy - worked on BZ 1113301
Miroslav Suchý is a good guy - removed FE-NEEDSPONSOR from BZ
1119056
Miroslav Suchý is a good guy - removed FE-NEE
It is my pleasure to announce that we just upgraded
https://copr.fedoraproject.org
It includes several major improvements:
* UI converted to PatternFly [1]. Most visible change is that tables
(e.g. list of builds) can be sorted using any column and you can filter
visible rows using any value.
Dne 23.7.2015 v 16:19 Chuck Anderson napsal(a):
> Would it be acceptable to bundle source packages, Buildroot itself,
> and my Buildroot configuration into one SRPM so everything is
> self-contained and can be built without requiring network
> connectivity? This means I would have to bundle the so
Dne 21.7.2015 v 19:28 Neal Gompa napsal(a):
>
> Accessing the Copr site is as slow as trying to search our Bugzilla (which
> is very slow indeed). Opening up pages
> describing Copr repos is slow too. I occasionally get browser timeouts
> accessing Copr. As for builds, those seem to be
> okay,
Dne 18.7.2015 v 04:11 Timotheus Pokorra napsal(a):
>> DEBUG util.py:378: failure: repodata/repomd.xml from updates: [Errno 256]
>> > No more mirrors to try.
>> > DEBUG util.py:378:
>> > http://infrastructure.fedoraproject.org/pub/fedora/linux/updates/20/i386/repodata/repomd.xml:
>> > [Errno 14] HT
Dne 21.7.2015 v 15:23 Neal Gompa napsal(a):
> It's extraordinarily slow right now, and builders don't have the level of
> availability needed to support it being part
> of the review process.
While this was true in past, this changed a lot in past two months.
Occasionally we have issues with PPC
Dne 11.7.2015 v 23:38 Jonathan Underwood napsal(a):
> Thoughts from the COPR folks?
I like the idea of adding Copr as intermediate step for new contributors. Copr
is outer ring of Fedora and it definitely
make sense for newbies to go from outer ring to ring0. Step by step.
Additionally we have i
Dne 1.7.2015 v 15:33 Robert Kuska napsal(a):
> I would like to start with Mass bug filing process and as stated
> at wiki, the first step is to gain consensus for what I want to make.
I maintain several python applications, but not all python libraries are
available for python3 yet.
Just few week
I have question about
https://fedoraproject.org/wiki/Changes/DisabledRepoSupport
We (as Copr developers) are thinking about one RFE. We would like to create
package which would contains .repo files and
gpg keys for every Copr project.
All of them with
enabled=0
enabled_metadata=1
But I won
Dne 29.6.2015 v 06:13 Dave Johansen napsal(a):
> I would like to start providing the latest version of ODB in a COPR for
> stable releases of Fedora and RHEL. Is there a
> "best practice" for this sort of thing?
>
> The main question I have is:
> Is it "better" to use a single repo and continue t
Dne 16.6.2015 v 23:00 Dennis Gilmore napsal(a):
> Hi all,
>
> Per the Fedora 23 schedule[1] we will be starting a mass rebuild for Fedora
> 23
> very shortly.
Will it be done using DNF of YUM?
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
dev
Dne 7.5.2015 v 10:17 Richard W.M. Jones napsal(a):
> For this reason, Fedora packages three different Unison branches in
> separate packages:
>
> - unison213 (currently Unison 2.13.16)
> - unison227 (currently Unison 2.27.57)
> - unison240 (currently Unison 2.40.128)
> - There was a "unison" p
Dne 12.6.2015 v 00:28 Kevin Kofler napsal(a):
> 1. The software we ship in Fedora (and that includes EPEL) should work out
>of the box. If you cannot provide DNF (with the plugins) in EPEL, then
>defaulting to yum is the only option.
>
> 2. The mock previously in EPEL actually worked for R
801 - 900 of 1079 matches
Mail list logo
