Dne 21. 12. 20 v 17:39 Neal Gompa napsal(a):
> On Mon, Dec 21, 2020 at 11:29 AM Ben Cotton wrote:
>> # Decompression happens inline with download. This has a positive
>> effect on resource usage: downloads are typically limited by
>> bandwidth. Decompression and writing the full data into a
Dne 19. 12. 20 v 21:24 Luya Tshimbalanga napsal(a):
> Just an idea of a form application that generates the spec file for newcomers
> as an example.
Something like
https://xsuchy.github.io/rpm-spec-wizard/
?
I do not propagate it too much as the first page needs a lot of love - it seems
Dne 17. 12. 20 v 10:17 Pavel Raiskup napsal(a):
>> I wonder how much slower it is?
> IOW, bootstrap image is even now slightly faster than normal bootstrap, but we
> could make it almost as fast as mock without bootstrap.
1) the difference is mostly in first run (till the cache is populated).
Dne 16. 12. 20 v 16:47 Fabio Valentini napsal(a):
> * #2519 F34 Change: GitRepos-master-to-main (decathorpe, 15:09:57)
> * AGREED: APPROVED (+6, 0, -0) (decathorpe, 15:27:51)
/me saving you time to read the log for **what** was actually approved:
15:19:05 Proposal: Approve proposal to
Dne 17. 12. 20 v 8:02 Luya Tshimbalanga napsal(a):
> Frontend for spec file
??? Can you elaborate it?
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To
I am looking for challenges for upcoming year - what I and my team should
enhance. I have some ideas, but I want to hear
yours.
What you - as Fedora packager - find most time consuming on packaging?
Where you will welcome more simplicity or automation?
--
Miroslav Suchy, RHCA
Red Hat,
Dne 15. 12. 20 v 11:39 Panu Matilainen napsal(a):
> BTW, I'm not aware of the details how the images are built these days, but of
> course *something* will still need to
> build those images,
That is normal podman image of Fedora.
Strictly speaking you will still need to have compatibility with
Regarding the recent announcement of CentOS 8 flipping to CentOS Stream - What
will be the configs for building EPEL 8?
I mean mock configs? And I ask as Mock maintainer - because I have no idea.
Are we going to build EPEL 8 against CentOS stream? What will happen when
CentOS stream flip to
Dne 14. 12. 20 v 11:22 Panu Matilainen napsal(a):
>
> When I started working on rpm back in 2007, landing new features to rpm meant
> looking 5+ years in the horizon to have
> said feature running on a released RHEL running in the builder so people
> could start trying it out on rawhide, which
Dne 04. 12. 20 v 15:25 Kevin Kofler via devel napsal(a):
> +1 for "rawhide" as the branch name.
>
> I have always seen the inconsistency between "rawhide" and "master" as a
> result of "master" being a default name in git. If we are going to change it
> anyway, we should change it to the real
Dne 03. 12. 20 v 20:02 Matthew Miller napsal(a):
> Mostly the latter. I don't even really care if they end up keeping the
> distinct os-release and etc.
Is this backed by some numbers and analysis?
My personal usage is that I create **hundred thousands** VM from Fedora cloud
image per year.
And
Dne 03. 12. 20 v 16:02 Ben Cotton napsal(a):
> * Release engineering:
>
>Releng will adjust any scripts that assume 'master' branch to use
> 'main' instead. The list includes and maybe few more
I do not see in the list upstream of dist-git.
I proceeded with:
Dne 03. 12. 20 v 16:31 Pierre-Yves Chibon napsal(a):
>>
>> * rpkg (fedpkg)?
>
>Wrapper to git, should not be impacted.
but is impacted.
There is bunch of
if rel == 'master':
return ['master']
which needs to be updated.
Also request_repo have hard-coded "master" name.
>> * COPR?
Dne 03. 12. 20 v 9:52 Vít Ondruch napsal(a):
> Yes, that was the idea. I can imagine, that the reason for your proposal is
> probably the not so straight forward
> transition from upstream name "foo" to Fedora name "python3-foo". But I am
> not expert on Python naming conventions.
The reverse
Dne 02. 12. 20 v 17:19 Vít Ondruch napsal(a):
> Why these requires does not follow some standard naming convention possibly
> with some prefix?
What do you mean? Like external:python3-foo?
> And actually wouldn't it be better to use some conditional dependency? One
> idea which comes to my
Dne 02. 12. 20 v 11:51 Miro Hrončok napsal(a):
> I can imagine myself using this locally when some test dependencies are
> missing (e.g. in RHEL). I hope it's possible to
> use this with `mock --install` and not just as BuildRequires. It is not clear
> from the linked GH wiki page.
I did not
Dne 01. 12. 20 v 13:07 Pavel Raiskup napsal(a):
> I'm pleased to announce that there's a new Mock release. Except for
> several bugfixes, this release introduces a new
> "External Build Requires" feature (by Miroslav Suchý)
I want to ask you for feedback on this feature.
htt
Dne 30. 11. 20 v 23:06 Tom Stellard napsal(a):
>
> If you are a package maintainer and would prefer to update your packages on
> your own, please do so before Dec 14, which
> is when I will begin doing the mass update.
python-satyr is false positive as it is EPEL only package
> abrt
Dne 30. 11. 20 v 23:06 Tom Stellard napsal(a):
> I will be doing the updates in batches, so that if there is a mistake the
> impact will be limited.
You mean: create PRs is src.fedoraproject.org?
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
Dne 30. 11. 20 v 19:29 Rudolf Kastl napsal(a):
> copr-cli has a --timeout option (in seconds). had the same issue with llvm.
WebUI has the the option as well when you specify new build.
> the default timeout from 18000 seconds (5 hours). You can set it to a max of
> 20 hours.
The default is
Dne 16. 11. 20 v 11:04 Vít Ondruch napsal(a):
> I should not propose this, because I agree with the points bellow. But if we
> should have it, then:
>
> ~~~
>
> Provides: upstream-spec(https://some.url/to/upstream/package.spec)
>
> ~~~
>
> would be machine readable and it would give use some
Dne 16. 11. 20 v 9:09 Elliott Sales de Andrade napsal(a):
>> This is actually a good idea. I have lots of such spec files.
>>
>> Is it a good idea to document this in Packaging Guidelines?
> It is already in the guidelines:
>
Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
> If you're going to have this kind of "upstream" spec file...well, I
> wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec
> files need to have a clear explanation that there is an "upstream" spec
> file, with a justification as
Dne 11. 11. 20 v 16:47 David Cantrell napsal(a):
> * #2475 proposal: let's develop the idea of a new repo for
> lightly-maintained packages (dcantrell, 15:16:41)
For the record - the initial ticket can be found here:
https://pagure.io/fesco/issue/2475
We already have "lightly-maintained
Dne 04. 11. 20 v 16:58 Will Crawford napsal(a):
> Does anyone know when this is likely to be available in COPR build roots?
Copr does not have any special repository. As soon as it hit stable (see Bodhi)
and the compose is made, then it is
available in Copr.
--
Miroslav Suchy, RHCA
Red Hat,
Dne 27. 10. 20 v 14:57 Matthew Miller napsal(a):
> I'm happy to announce that Fedora 33 is here. Thank you to the
> thousands of people who worked on this release in some way, and to all
> of our community. Fedora 33 is made of bits, but the Fedora Project is
> made of people, and you are all
I orphaned perl-Math-FFT:
https://src.fedoraproject.org/rpms/perl-Math-FFT#
I do not use it for long time.
It is basicaly no-op package. But I just got notified that there is a new
version.
Feel free to take it.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno,
Dne 13. 10. 20 v 0:43 Jerry James napsal(a):
If you have an interest in OCaml packaging, stop by and help knock off
some of the TODO items. Regards,
Feel free rebuild all OCaml packages and provide them in Copr project.
Similarly as @iucar did for CRAN:
Dne 07. 10. 20 v 11:47 Daniel Pocock napsal(a):
> Is Mock only intended for building things or the chroot created by Mock
> can be considered a long-lived chroot for daily use?
The original purpose is a build tool.
But I see many people to do:
mock -r fedora-33-x86_64 shell
> With the move
Dne 05. 10. 20 v 17:20 Frank Ch. Eigler napsal(a):
> The problem is that Fedora itself doesn't run a server, and our test
> server can afford to carry only a subset of debuginfo/debugsource rpms
> & architectures. So, fedora developers / users cannot get at all the
> info, or from an official
Dne 06. 10. 20 v 23:50 James Cassell napsal(a):
> yum install --releasever=/ --installroot=/mnt/sysimage bash mypackage
This is naive approach. It does not setup: resolver, timezone, dbus uuid,
unpriv user, btrfs-control, special devices, etc.
Yes, for most quick'n'dirty use cases you will not
Dne 03. 10. 20 v 23:28 Tom Seewald napsal(a):
> Error: Transaction test error:
> file /usr/lib/.build-id/0e/fd9f1f23d7cefd37989b7d1b401b4994fee742 conflicts
> between attempted installs of openjfx-11.0.3-1.fc33.x86_64 and
> openjfx8-8.0.202-24.b07.fc33.x86_64
> file
Dne 05. 10. 20 v 12:55 Tomas Hrnciar napsal(a):
> copr-messaging schlupov
Fixed in upstream.
https://pagure.io/copr/copr/pull-request/1534
Will propagate to Fedora soon.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
Do you want to make Fedora 33 better? Please spend 1 minute of your time and
try to run:
# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'
sudo dnf --releasever=33
Dne 08. 09. 20 v 10:51 Petr Pisar napsal(a):
>> I'm debugging an issue in a FTBFS, which appears caused by unexpected
>> warnings during a build [1]. These warnings come from R and complain
>> that /etc/localtime is not a symlink.
> I hit this issue many years ago and tzdata maintainer claimed
>
Dne 31. 08. 20 v 23:35 Adam Williamson napsal(a):
> On Mon, 2020-08-31 at 15:53 -0400, Ben Cotton wrote:
>>
>> Accepted blockers
>> -
>> 1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST
>> abrt-server errors when processing zstd compressed core dumps
As part of
https://github.com/rpm-software-management/mock/issues/382
I found that the very minimal spec file can be built only using:
* shadow-utils - mock needs /usr/sbin/useradd from this package
* rpm-build - mock needs /usr/bin/rpmbuild
* glibc-minimal-langpack - this is optional,
Dne 30. 06. 20 v 20:17 Christopher napsal(a):
> Hi,
>
> I know Fedora doesn't directly support Amazon Linux, but I was
> wondering if the package maintainer for rpmconf on EPEL was aware that
> the latest version doesn't work on Amazon Linux 2, which recently
No, I was not aware of that :)
>
Dne 24. 06. 20 v 4:40 Przemek Klosowski via devel napsal(a):
> dnf -C list extras
How do I skip packages which are installed from @@commandline? Is there
anything else than "grep -v"?
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
Dne 24. 06. 20 v 21:03 Iñaki Ucar napsal(a):
> 3. Use audit2allow to convert them to rules.
> 4. Repeat until you don't get any more complaints.
>
> And I cannot believe my eyes. Is this *really* the way to implement
> SELinux policies? It seems like a joke to me.
No. It is a bit complicated.
Dne 25. 06. 20 v 16:06 Igor Raits napsal(a):
> I think removing that dependency is simply wrong. It essentially means
> that one would not be able to use those scripts without dependency
> being installed.
Simply removing is wrong. But I see nothing bad on moving it to Recommends or
even
Dne 15. 06. 20 v 21:47 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
I am moving back this proposal.
I want to thank all of you for the feedback. I was surprised by lots
Dne 17. 06. 20 v 15:01 Miro Hrončok napsal(a):
> However, my question in the original email remains unanswered.
>
> What kind of mock builds need Fedora modular repos inside the mock root?
> I thought mock uses repos defined in mock roots configuration.
Miro is right, and I raised it
Dne 16. 06. 20 v 3:05 Neal Gompa napsal(a):
> So I'm confused here, does anyone know why the animated wallpapers
> don't work in KDE Plasma or any other desktop? I personally love
> animated wallpapers and I'd like to see this on my KDE Plasma desktop
> too...
>
https://store.kde.org/p/1295389
Dne 16. 06. 20 v 9:56 Vít Ondruch napsal(a):
> 1) It does not reflect, that this is not just about retired packages,
> but also (or mainly?) about subpackages, which we don't retire.
>
> 2) The point (1) is closely related to -debuginfo packages topic [1]
> which I re-raised recently with not as
Dne 15. 06. 20 v 22:10 Ben Cotton napsal(a):
> We install/keep fedora-repos-modular by default, users (admins) can
> uninstall it if desired. No defaults are changed
How you manage to have it installed by default? It is not obvious from the
linked PR to me.
I just want to be sure it will be
Dne 16. 06. 20 v 0:37 James Cassell napsal(a):
> Please not using mechanism. Make it easy to opt out, or better yet opt-in.
On package level, there is likely no other way. DNF team will have no
time/resources to implement this on DNF level.
I can only thing of /usr/sbin/remove-retired-package
Dne 16. 06. 20 v 0:40 Ian McInerney napsal(a):
> and then cleaned them off manually (listing them through `rpm -qa | grep
> fcXX` and then manually removing them), but I
> think it would be better to warn on upgrade when those packages don't exist
> in the newer release to tell the user they
>
Dne 15. 06. 20 v 22:43 Solomon Peachy napsal(a):
> This will silently break otherwise-working software on production
> systems, and provide no straightforward way to get back to a working
> state.
Can you give example?
> What about software installed from 3rd-party repositories? What about
>
Dne 06. 06. 20 v 12:52 Andy Mender napsal(a):
> - https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package
This is old version of "how to write simple SPEC file". Albeit, still valid.
Several times, I wanted to delete it as we now have:
Dne 02. 06. 20 v 18:40 Kevin Fenzi napsal(a):
> 2020-06-09 tue: The build and packaging ecosystem. This includes koji,
> src.fedoraproject.org, osbs, odcs, container registries, bodhi (updates
> system). During this day maintainers should avoid builds/updates if at
> all possible as they may or
Dne 02. 06. 20 v 18:40 Kevin Fenzi napsal(a):
> 2020-06-09 tue: The build and packaging ecosystem. This includes koji,
> src.fedoraproject.org, osbs, odcs, container registries, bodhi (updates
> system). During this day maintainers should avoid builds/updates if at
> all possible as they may or
Dne 02. 06. 20 v 18:40 Kevin Fenzi napsal(a):
> 2020-06-09 tue: The build and packaging ecosystem. This includes koji,
> src.fedoraproject.org, osbs, odcs, container registries, bodhi (updates
> system). During this day maintainers should avoid builds/updates if at
> all possible as they may or
Dne 24. 05. 20 v 10:02 Mattia Verga via devel napsal(a):
> - following the Policy for stalled package reviews [1], I would like to
> mass comment on tickets submitted before 1/1/2017 (more than 3 years
> old) asking the submitter if they're still interested in continue with
> the review process
Dne 21. 05. 20 v 10:52 Ankur Sinha napsal(a):
> Hi folks,
>
> The packaging team is generally quite stretched, and we frankly need
> more people helping us out.
>
> The main issue with newcomers taking on packaging is that the learning
> curve here is much more technical then a lot of other
Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a):
> Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8. But
> instead of asking ourselves, "should we push
> in the VERY latest Python and hope it's ok?", we just patch the build system
> to accept it anyway and hope for the best.
>
Dne 11. 05. 20 v 9:43 Zbigniew Jędrzejewski-Szmek napsal(a):
> , IMHO it would be better to make the user interface
> stronger: have dnf say what is removed and why (when obsoleted)
+1
But we should realize that DNF actually does not have user interface. IMHO this
should be only exposed using
Dne 06. 05. 20 v 15:12 Miro Hrončok napsal(a):
> This has downsides: When the files are changed in next update, I won't get
> them updated, because they are shipped as
> %config(noreplace). (If they were not shipped as %config(noreplace), it would
> be even worse, as my changes would be
>
Dne 04. 05. 20 v 17:05 Tomas Tomecek napsal(a):
> The main reason I am sending this is to gather feedback from all of
> you whether there is an interest in such a workflow.
I am +1 as long as:
a) this is opt-in (cannot imagine anything else)
b) you resolve the gordic knot of easy sync of changes
Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> So, in my experience, source-git might be a workable solution for
> packages with *big* downstream modifications.
Big +1. Been there, done that (with Tito).
> In the rare occasion that I need to make downstream-only changes with
> patches, I
Dne 29. 04. 20 v 18:07 Miroslav Suchý napsal(a):
> Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
>> Based on the recent discussions around %fedora/%rhel macros and ELN,
>> and %bcond generally being confusing to work with, I came up with a
>> distribution-wide feature that de
Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
> Based on the recent discussions around %fedora/%rhel macros and ELN,
> and %bcond generally being confusing to work with, I came up with a
> distribution-wide feature that defines generic feature keywords and
> associated helper macros that packages
Dne 28. 04. 20 v 15:55 Matthew Miller napsal(a):
> It’s here! We’re proud to announce the release of Fedora 32.
> Thanks to the hard work of thousands of Fedora community
> members and contributors, we’re celebrating yet another
> on-time release!
>
> Read the official announcement at:
>
> *
Dne 06. 04. 20 v 18:28 James Cassell napsal(a):
> My understanding of current policy is that it would not be permitted to have
> such a module in current fedora.
"is permitted in Fedora" vs. "is technically possible" are two different things.
Technical specification should think about layered
Dne 07. 04. 20 v 17:43 Scott Talbert napsal(a):
> Is there a recommended way for detecting when a package is being built under
> mock?
In Mock, we try as much as possible mimic normal system. So - no, there is no
way I can recommend.
> I have a package where some tests
> fail due to various
Dne 31. 03. 20 v 8:26 Panu Matilainen napsal(a):
> # rpmdb --rebuilddb
I always wanted to ask: how the rebuilddb works? The man page states that rpmdb
rebuilds db from package headers. Where
are those headers stored?
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno,
Dne 27. 03. 20 v 8:55 Zbigniew Jędrzejewski-Szmek napsal(a):
> In current "offline upgrade" scheme, the upgrade
> tools are running on the real system, with udev active.
How the "offline upgrade" works under hood? Do I understand correctly that even
"offline ugprade" will have problem with
Dne 23. 03. 20 v 11:07 Lumir Balhar napsal(a):
> Hello, Fedora developers.
>
> We, members of Fedora Machine learning SIG, are looking for a ways how we can
> help you with ML and make Fedora the best
> ML platform for developers, researchers and scientists.
>
> - Do you know about any problem
The dist-git is now emitting the messages via fedmsg. Whenever new upload has
been done.
As fedmsg is dead (long live fedora-messaging), I wonder if someone is actually
consuming those messages? Should we
migrate the code? Or is it save to drop this functionality?
If I did not get any response
Dne 04. 03. 20 v 20:04 Ankur Sinha napsal(a):
> Problem 1: conflicting requests
> - nothing provides module(platform:f31) needed by module
> bat:latest:3120190813194409:22d7e2a5-0.x86_64
> Problem 2: conflicting requests
> - nothing provides module(platform:f31) needed by module
>
Do you want to make Fedora 32 better? Please spend 1 minute of your time and
try to run:
# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'
sudo dnf --releasever=32
Dne 03. 03. 20 v 17:07 Steve Grubb napsal(a):
> However, I'm finding that on a typical system, there are about 20 packages
> that place python byte code in /usr/share.
Can you elaborate? Which packages? What files?
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno,
Dne 24. 02. 20 v 18:13 Miro Hrončok napsal(a):
> Can we please have a "git is the only source of truth" version of this? I.e.
> "Compute the release field from the number
> of commits since the last version change" in the document. It seem to only
> have one con (breaks if two builds are
>
Dne 24. 02. 20 v 11:17 Vitaly Zaitsev via devel napsal(a):
> All packages must be build with disabled network access to ensure, that
> it use packaged dependencies and not downloaded from outside.
Yes. But it is only rpm-build what cannot access network. Mock itself can
access network.
In other
Dne 21. 02. 20 v 15:57 Martin Sehnoutka napsal(a):
> This process is unfortunately not fully automated and therefore requires a
> certain amount of human effort.
This is an important sentence. Let's save it for later as [1]
> The proposal itself is fairly simple: Let’s stop packaging all Go and
tl;dr: On Sunday 23rd February, there will be Copr outage. It will last the
whole day.
PPC64LE builder and chroots will be deactivated. The PPC64LE builders should be
back in a matter of weeks.
Hi.
As previously announced, Fedora's infrastructure is moving to a different
datacenter. For some
Dne 04. 02. 20 v 13:18 Till Hofmann napsal(a):
> Does COPR itself also use the CDN for builds? I usually build dependency
Yes. Since today.
> chains, and since this morning, I see a lot of build failures due to a
> newly built package not being available. One example:
> - The newly built
Dne 02. 02. 20 v 13:13 Mattia Verga via devel napsal(a):
> I don't have enough competence to start such a big project, but if
> anyone is interested I could give a hand.
People are asking for this for years. No one ever had time to do this. This
make you most competent guy :) Just do it.
We
Hi,
I just enabled the content delivery network (CDN) for Copr repositories.
It is provided by CloudFront from AWS. And it is provided for free by Amazon to
Fedora.
Technically the original URL
copr-be.cloud.fedoraproject.org
is now accessible using
download.copr.fedorainfracloud.org
The
Dne 31. 01. 20 v 8:03 Igor Gnatenko napsal(a):
> Hello,
>
> I am working on packaging
> [netbox](https://github.com/netbox-community/netbox/) which is
> basically web service which is run via gunicorn and then it is up to
> admin to decide whether he wants to use nginx, httpd or anything else.
>
Dne 22. 01. 20 v 12:03 Kevin Kofler napsal(a):
> I also do not understand why 6 TB of disk space is such an issue in times
> where one single HDD can carry up to 16 TB.
Because you need more of them because of RAID. And because once you reach the
roof - 16 GB atm - the price does not grow
Here is the summary of recent voting:
https://docs.google.com/document/d/1DClOxQADo-KqC18KK-RPmz2awRNpRt1W5z_xnWfMFd8/edit?usp=sharing
Quick summary - topics sorted by priority (higher got more votes for priority]:
* better automatic builds triggered by github, gitlab...
* More parallel
Dne 15. 01. 20 v 18:07 Ian Pilcher napsal(a):
> Is $SUBJECT possible these days?
>
> I've tried with both --bootstrap-chroot and --use-bootstrap-image, but
> the build is failing with:
>
> ERROR: builddep command missing.
> Please install package dnf-plugins-core.
>
> This happens even when
Dne 15. 01. 20 v 18:05 Miro Hrončok napsal(a):
> ### Solution 2: Move developer oriented modules to python3-devel (or split
> the stdlib into pieces)
+1
> ### Solution 5: Stop shipping mandatory bytecode cache
+1
> Problem 5.1: Slower starts without bytecode cache
Especially in
Dne 13. 01. 20 v 14:05 Vít Ondruch napsal(a):
> %changelog
>
> %include changelog
+1
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
Dne 11. 01. 20 v 3:54 Neal Gompa napsal(a):
> * %{dist}..
-1
Packages with commitish in release version are usually developers snapshot.
We already have few packages with such release in Fedora, but I would dislike
to make this standard.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager
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
*
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
Dne 08. 01. 20 v 17:59 Neal Gompa napsal(a):
> This is an interesting idea, but I'd really like to see an integrated
> registry offering in Copr
This would require MUCH bigger storage. I estimated it 100+ TB.
Red Hat donated us 20TB storage, but that is enough just for RPMs not for
container
Dne 08. 01. 20 v 11:15 Fabio Valentini napsal(a):
> How do I actually enable this? I can't find it, neither in the web
> interface, nor in copr-cli.
> It would be useful to have this set up for my elementary-nightly COPR,
> since there are 1+ builds in there, accumulated since 2015, and I
>
Dne 08. 01. 20 v 11:18 Dan Horák napsal(a):
> if COPR can utilize remote (cloud) resources, I would concentrate on
> such way. When we will know the requirements, we can work with our
> partners to allocate them.
Copr can use cloud. Or almost anything. We use OpenStack. We have AARCH64
builders
I want to sum up what happened in Copr during 2019. At the end of this email,
you can see our TODO list and cast your
vote on what we should focus on.
During the year 2019:
* we added native AARCH64 builders
* we added emulated ARMhfp builders
* released eight new versions of Mock including
Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a):
> The thing is that no matter how much you can manage to automate the
> creation of spec files for a given ecosystem, and I've never seen one
> where the typical spec file doesn't need some manual tweaking, you
> are still going to hit the fundamental
Dne 06. 01. 20 v 18:19 Matthew Miller napsal(a):
> We're not adding meaningful end-user value by manually repackaging these in
> our own format. We _do_ add value by vetting licenses and insuring
> availability and consistency, but I think we can find better ways to do
> that.
COPR can play
Hi,
I just orphaned perl-Filesys-Df. Feel free to take it.
This is basically nothing-happening-here package. It needs EPEL8 build:
https://bugzilla.redhat.com/show_bug.cgi?id=1785649
I do not use this package for long time and I do not even code in Perl for long
time.
This package is
Dne 28. 10. 19 v 20:59 Troy Dawson napsal(a):
> [3] - The core buildroot is the packages in @buildsys-build, and
> everything needed to build those packages.
[4] - self-hosting is the ability to build all the packages on themselves.
Why?
Why, this needs to be self-hosting? Do we really
Dne 15. 11. 19 v 19:27 Przemek Klosowski napsal(a):
YOu mean directly f26-f31?
Nope. I meant f26->f27->f29->f30->f31.
The upgrades goes fine. But each of those upgrades leaves bunch of python2 modules on disk. These, which cause upgrade
issues, I report to fedora-packages-obsoletes.
Right
Dne 15. 11. 19 v 13:50 J. Scheurich napsal(a):
Hi,
I want to approve the review request of vimvi-qt, but this is my first
offical review 8-(
https://bugzilla.redhat.com/show_bug.cgi?id=1770278
I can't find the right page to do that.
Can someone help me ?
Dne 15. 11. 19 v 13:37 Miro Hrončok napsal(a):
however I don't think looking that back is worth it.
I've seen a lot of people who were upgrading back from Fedora 1X. I am
upgrading my notebook from F26.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
Dne 15. 11. 19 v 10:21 Victor Stinner napsal(a):
I'm not sure if we need a Fedora change just for a compiler flag. Again, the
only drawback is that we will no longer be able to override a symbol using
LD_PRELOAD. Honestly, I never did that. I don't see any use case for that. But
I used
401 - 500 of 1005 matches
Mail list logo
