:
>
> On 05. 10. 23 21:52, Ken Dreyer wrote:
> > Hi folks,
> >
> > I have some Python apps that "import dnf". I wanted to run these on
> > the parallel Python versions in RHEL 8 and 9, but there's no
> > python311-dnf library available.
> >
> &
Hi folks,
I have some Python apps that "import dnf". I wanted to run these on
the parallel Python versions in RHEL 8 and 9, but there's no
python311-dnf library available.
I haven't looked into this yet. Has anyone else looked at it?
I think I'll need something like
On Fri, Mar 11, 2022, 8:53 AM Peter Robinson wrote:
> > On Thu, Mar 10, 2022 at 9:45 AM Colin Walters
> wrote:
> > > Long term if Bugzilla slowly morphs into only being used by Fedora,
> > > personally I'd prefer to have bugs/issues in gitlab instead.
> >
> > Yes, I personally think gitlab.com
On Thu, Mar 10, 2022 at 9:45 AM Colin Walters wrote:
> Long term if Bugzilla slowly morphs into only being used by Fedora,
> personally I'd prefer to have bugs/issues in gitlab instead.
Yes, I personally think gitlab.com would be a good replacement for
src.fedoraproject.org and
On Wed, Mar 2, 2022 at 2:16 PM Jakub Jelinek wrote:
>
> On Wed, Mar 02, 2022 at 01:29:00PM -0500, Ben Beasley wrote:
> > In RPM packaging, of course, everything is built from scratch, usually with
> > LTO, and a package that takes a minute to link probably takes an hour to
> > build. While any
On Wed, Feb 16, 2022 at 4:09 AM Nikola Forró wrote:
> Hello,
>
> is there anybody willing to review python-specfile [1]?
Your email made me look at this upstream
(https://github.com/packit/specfile). It looks interesting! I wonder
if we could use it more broadly (like for pyrpkg). It reminds me
Hi folks,
I've been researching IMA signing with RPM. This is a new feature in
CentOS 9 that has not been enabled in Fedora
I'm not an IMA expert, and I don't work on this for Red Hat, I'm just
an interested user. (In particular, I'm interested in how our build
systems track signatures, and how
On Mon, Jan 17, 2022 at 4:44 PM Ken Dreyer wrote:
> Something else I'm wondering: rpmsign writes those four-byte "keyid"
> values to my FILESIGNATURE entries even if I don't have a public cert
> at all. How does it do that? I see verify_rpm.py checks the RPM's
> keyid va
On Thu, Jan 6, 2022 at 5:17 AM Patrick マルタインアンドレアス Uiterwijk
wrote:
> > - How do I generate my own new keypair so I can IMA-sign an RPM?
>
> You can generate the key with the standard OpenSSL commands.
> For example, an RSA key can be generated like:
> openssl genrsa | openssl pkcs8 -topk8
Hi folks,
When I run "fedpkg mockbuild" for my epel8 dist-git branches, it fails
with the following error:
Error: Error downloading packages: Status code: 403 for
Hi folks,
I want to add "intro to IMA signing" instructions to
https://docs.pagure.org/koji/signing/ . I wrote a basic PR at
https://pagure.io/koji/pull-request/3206 but it lacks technical
details.
- How do I generate my own new keypair so I can IMA-sign an RPM?
- Can I use my existing GPG
On Tue, Nov 30, 2021 at 2:41 PM Otto Urpelainen wrote:
>
> Have you considered submitting a link to this to the Koji docs? A while
> ago, I tried to set up a dev Koji environment just by following the
> docs. Having a pointer to this would have been very useful.
No, but that's a good idea!
On Sun, Oct 10, 2021 at 2:33 PM Dan Čermák
wrote:
> > Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small
> > set of Fedora infra, including Koji+Bodhi.
>
> How about a vagrant box or a docker-compose file :)
>
> However, I'm a little worried that this might be too fat or not
On Sat, Oct 16, 2021 at 11:09 AM Richard W.M. Jones wrote:
>
> Looks like several people have reinvented wheels here because Fedora
> doesn't really offer this.
I've wanted to make more use of virt-builder. Here is the bug that I
last encountered with this:
On Wed, Oct 13, 2021 at 2:21 PM Neal Gompa wrote:
> Unfortunately, we lack a usable equivalent for releases, though that's
> good to know for Rawhide.
For that I use the following URL format string:
On Tue, Oct 12, 2021 at 3:26 PM Adam Williamson
wrote:
> Hanging over all of this is the threat that PDC might go away at some
> point, which would be a bit of an inconvenience. In A World Where there
> is no PDC, you have to grab the metadata files for composes that still
> exist from kojipkgs;
On Sun, Sep 26, 2021 at 2:25 PM Miro Hrončok wrote:
>
> On 24. 09. 21 21:45, Ken Dreyer wrote:
> > This means that python-pytest-cov and python-pytest-xdist won't be
> > available on epel9, since those require gevent.
>
> Ignoring the rest of your email for now, but I don
On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer wrote:
>
> https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm
On the one hand, thank you for pointing out that this build is now
available. That's good to know.
On the
Hi folks,
The RHEL 9 composes do not have libev-devel and libuv-devel, so we
cannot build python-gevent on EPEL 9 easily.
(It's possible to package the missing -devel packages separately, and
I've been doing this by automatically following the NVR changes in
Stream 9's Koji for several weeks
On Fri, Sep 10, 2021 at 2:11 PM Stephen John Smoogen wrote:
> Small correction. Miroslav didn't say COPR uses ccache. He said COPR
> uses ramdisk for mock.
Oh, whoops. Got it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
On Fri, Sep 10, 2021 at 9:33 AM Miroslav Suchý wrote:
> We use this in Copr. AFAIK Koji does not use it. You can join Fedora infra to
> change it :)
Is there more documentation about how Copr uses ccache? I was grepping
around https://pagure.io/copr/copr for "ccache" and I see the
On Thu, Sep 9, 2021 at 1:01 PM Neal Gompa wrote:
> We'd need icecream[1] support enabled in Koji. I am not even sure Mock
> (the build engine) supports icecream right now.
This is on my list of things to investigate one day. Ceph has the same
problem - builder machines with 16GB RAM can barely
On Mon, Jul 19, 2021 at 7:06 AM Björn Persson wrote:
>
> I suspect that many users are like me: I don't want to constantly be a
> guinea-pig for the whole testing repository, but if I could be notified
> about updates of certain packages I'm interested in, then I could
> choose to test those if
On Thu, Jul 8, 2021 at 11:08 AM Michel Alexandre Salim
wrote:
> I might eventually extend python-bugzilla a bit to make it easier to
> do this. A lot of the operations seem to assume it's a small Bugzilla
> instance an would try to pre-load all the components for a given
> product.
Your comment
On Fri, Jun 18, 2021 at 4:24 AM Vít Ondruch wrote:
>
> I always use `fedpkg import` and this command has `--offline` option,
> which populates the `sources` file without uploading the archives to the
> look-a-side cache.
Oh, nice, I did not know of that command. Thanks.
On Thu, Jun 17, 2021 at 8:33 AM Richard Shaw wrote:
>
> On Thu, Jun 17, 2021 at 7:22 AM Ewoud Kohl van Wijngaarden
> wrote:
>>
>>
>> To be clear: I don't want to fiddle with the sources file, hence this
>> email. However, I would like to at least complete a local mockbuild
>> before uploading
Does "fedpkg gitbuildhash" do what you want?
Source is gitbuildhash() method in
https://pagure.io/rpkg/blob/master/f/pyrpkg/__init__.py
On Fri, Feb 26, 2021, 5:54 PM Audrey Toskin
wrote:
> I'm interested in looking up the source used for different builds on Koji
> -- particularly the exact
On Sat, Feb 13, 2021 at 3:06 PM Ken Dreyer wrote:
>
> On Mon, Jan 4, 2021 at 9:52 AM Miroslav Suchý wrote:
> > * Contribute to fedpkg/koji to have machine-readable output.
>
> There is a "--json" argument to "koji call", and that produces
> machine
On Mon, Jan 4, 2021 at 9:52 AM Miroslav Suchý wrote:
> * Contribute to fedpkg/koji to have machine-readable output.
There is a "--json" argument to "koji call", and that produces
machine-readable output for individual Koji RPCs.
It would be really nice if rpkg had something similar, or even an
On Wed, Feb 3, 2021 at 8:42 PM Neal Gompa wrote:
> The Koji build system already records buildinfo data in a slightly
> different form, where build IDs are linked to all the inputs that
> constructed the build environment as recorded by Koji itself. This
> implicitly includes a definition of all
selinux-policy-base, and testing each new build of your
> module on a system with that fixed version of selinux-policy-base.
>
> However, it would be best to avoid cross-sytem installations.
>
> Hope this helps.
>
>
> Vit
>
>
> [1] - https://access.redhat.com/articles
On Wed, Jan 27, 2021 at 9:17 AM Vít Ondruch wrote:
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should be
> the preferred way. Would there be anybody really missing this functionality?
Seems like this is a
Hi folks,
Many applications ship their own "-selinux" sub-package. These
subpackages usually set a minimal dependency on the exact
selinux-policy version in the buildroot.
In Ceph's case, we have:
Requires(post): selinux-policy-base >= %{_selinux_policy_version}
This version requirement
On Wed, Jan 6, 2021, 5:49 PM Kevin Fenzi wrote:
> On Wed, Jan 06, 2021 at 10:20:59PM -, Endi Sukma Dewata wrote:
> > Hi, there seems to be a problem with libuv on F32.
> > It doesn't seem to be happening on F33. Is anybody
> > familiar with this? Thanks.
>
> I'm not sure how this could
On Sun, Dec 27, 2020 at 7:38 PM Kevin Fenzi wrote:
> You can add more than one. Just put them in a file and upload all of
> them for 'ssh key' one key per line. There's a limit based on
> applications getting the ssh keys, but you can upload multiple keys
> fine.
Oh, ok! Thanks.
On Thu, Dec 24, 2020 at 12:33 AM Dridi Boukelmoune
wrote:
>
> > The weakest point in the current system is really the FAS password. If
> > you have a packager's FAS password you can change the ssh key
> > associated with the account to another that you control, and the FAS
> > password is also
On Tue, Dec 22, 2020, 2:39 PM Adam Williamson
wrote:
> So that proposal was just for all packagers. I think it should at least
> be reasonable to set a relatively high bar for being a provenpackager.
Agreed that there's a higher bar here. I think the privilege should be
revoked if you've not
On Thu, Dec 10, 2020 at 12:52 PM Matthew Miller
wrote:
> Thanks for filing this, and I'll highlight it for the modularity team's
> attention.
Thanks. I also filed https://pagure.io/fm-orchestrator/issue/1629 a
while back. I think this could help users understand MBS a bit better.
- Ken
On Tue, Dec 8, 2020, 3:18 PM Matthew Miller
wrote:
> On Tue, Dec 08, 2020 at 08:02:01AM -0700, James Szinger wrote:
> > I find the modularity end-user documentation to be woefully
> > inadequate, especially for developers.
>
> Is there a particular part of the documentation you're struggling
On Fri, Dec 4, 2020, 3:25 PM Matthew Miller
wrote:
> On Fri, Dec 04, 2020 at 02:16:23PM -0800, Japheth Cleaver wrote:
> > be a better-engineered and tested option. But as time goes on and
> > the next EL release isn't either isn't announced or isn't stable
> > enough to rely on, Fedora Server
On Sun, Nov 15, 2020 at 5:13 PM Jason Edgecombe wrote:
> In my personal time, I'm learning a little about fedora packaging in order
> to build some Fedora packages on RHEL8/CENTOS8 for my personal use. I'm
> somewhat familiar with RPM spec files and building RPMs.
Welcome Jason!
- Ken
On Fri, Nov 13, 2020 at 3:23 PM Matthew Miller wrote:
> That reason was _mainly_ to erase the inside Red Hat,
> community-around-the-edges distinction. That was a huge success and Fedora
> wouldn't be interesting without that. But I think the _technical_ choice was
> in retrospect a mistake.
On Thu, Nov 12, 2020, 4:15 PM Matthew Miller
wrote:
> On Fri, Nov 13, 2020 at 12:07:29AM +0100, Kevin Kofler via devel wrote:
> > I still believe that this concept is inherently incompatible with the
> idea
> > of a cooperative community distribution, and that bringing it up again
> and
> >
On Wed, Sep 9, 2020, 6:50 AM Petr Pisar wrote:
> On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> > To solve this problem, I am proposing that we create a new repository
> called
> > EPEL 8 Next.
> >
> > - built against CentOS 8 Stream
> > - opt-in for packagers (must request
On Fri, Jun 19, 2020 at 9:16 AM Stephen Gallagher wrote:
> I love how people hold up "containers" as a solution to these problems
> without considering for a moment how exactly the container itself gets
> built. If you were to look into the flatpak build system in Fedora,
> you'd see that they
On Thu, Jun 18, 2020 at 1:27 PM Josh Boyer wrote:
> I don't think burst-to-cloud means we only burst to a single cloud.
> That seems like a great way to just lock into that cloud with no
> flexibility. Rather, I would look at it as a hybrid cloud opportunity
> and use AWS, or the IBM cloud that
On Thu, Jun 18, 2020 at 10:31 AM Josh Boyer wrote:
> Personally, I have long wanted burst-to-cloud or the ability for
> others to donate hosts to the Fedora build system without having to
> physically ship hardware. Koji is somewhat limited in that regard.
> Maybe developing a shim layer and
It is amazing to me how often this setting makes things work.
It seems like we're hard-coding this to "1" more widely.
On Tue, May 19, 2020, 12:01 PM Paul Howarth wrote:
> On Tue, 19 May 2020 09:21:46 -0700
> Kevin Fenzi wrote:
>
> > On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John
On Wed, May 13, 2020 at 4:29 PM clime wrote:
> Probably there are more variants but I see these three right now. I
> think variants 1 and 2 where the spec file is kept in dist-git but
> patches can be in source-git are more within our reach right now (but
> I might be wrong, variant 3 is also
On Tue, May 12, 2020 at 6:20 PM clime wrote:
> When you do rdopkg new-version and you are asked to force push, is
> also the current master-patches HEAD tagged with the current package
> NVR?
It's something that I have to do before I run "new-version". Here's
the command I ran today:
$ rdopkg
On Tue, May 12, 2020 at 1:45 AM clime wrote:
>
> Ken, would it be, please, possible to provide links to the patch
> branches and mentioned dist-git repos. I would like to have a closer
> look.
Sure. I can't share the links to the RH Ceph Storage dist-git repos,
so I will give one example where I
On Sun, May 10, 2020 at 11:51 PM Petr Pisar wrote:
> How do you backport fixes? Do apply the fixes directly to dist-git? Or do you
> apply the fixes to a corresponding patches branch that you occur to have
> around till needed (e.g. till the hitorical code is supported) for the purpose
> of
On Wed, May 6, 2020 at 2:24 PM Simo Sorce wrote:
>
> Well, a way to allow force pushes would be to have a git hook that
> branches the tree before the force push. (creating a branch named
> something like audit-force-push-)
In Ceph we do this at a slightly different point of time. We use
"rdopkg
For several years I've run my kickstart installs through a squid proxy
that caches packages that I download. My kickstarts have something
like this:
url
--url=http://mirror.chpc.utah.edu/pub/fedora/linux/releases/31/Everything/x86_64/os/
--proxy=http://squid.example.com:3128
As I test many
On Tue, Mar 10, 2020 at 11:55 AM Kevin Fenzi wrote:
>
> when you see a proxy name there it usually means you have rdns true in
> /etc/krb5.conf (it should be false), or krb_rdns or krb_canon_host true
> in /etc/koji.conf or ~/.koji.conf (should be false).
I think those options only apply to the
On Mon, Feb 17, 2020 at 10:52 AM Adam Williamson
wrote:
> Since this is an API endpoint of a real system which needs to be
> updated correctly when the release events actually happen, it should
> have the benefits pkgdb used to be (the information should be reliable
> and timely)
Do we have
On Thu, Feb 13, 2020 at 5:54 AM Matthew Miller wrote:
>
> In EPEL 8 or later, it is permitted to have module streams which contain
> packages with alternate versions to those provided in RHEL. These packages
> may be newer, built with different options, or even older to serve
>
On Fri, Feb 7, 2020 at 3:19 PM Kevin Fenzi wrote:
>
> On Fri, Feb 07, 2020 at 01:46:26PM -0700, Ken Dreyer wrote:
> > I'm not sure where to report such an RFE. Is
> > https://github.com/release-engineering/dist-git right?
>
> yep. Exactly the right place.
Thanks, I o
On Fri, Feb 7, 2020 at 3:48 AM Lubomír Sedlář wrote:
> It seems you accidentally uploaded the source RPM instead of the
> tarball. Simply run fedpkg new-sources on the correct file and push the
> new sources file. The build should then work.
Can we have a blacklist on the dist-git lookaside
On Thu, Jan 23, 2020, 9:04 AM Stephen John Smoogen wrote:
> On Wed, 22 Jan 2020 at 06:04, Kevin Kofler wrote:
> >
> > Kevin Kofler wrote:
> > > IMHO, this whole "delete by default" concept is inherently flawed and
> > > dangerous and cannot be fixed. Notification e-mails can be lost in so
>
On Thu, Jan 30, 2020 at 3:59 PM Robbie Harwood wrote:
> Richard Shaw writes:
>
> > Not replying to anyone in particular but to the thead as a whole...
> >
> > 1. Nothing in the packager introduction process prepares a packager
> > for what to do when they get a CVE filed against one of their
> >
On Wed, Jan 29, 2020 at 7:18 AM Remi Collet wrote:
> There are different:
>
> * Changelog is for end user
> * Git log is for package maintainer
I completely agree with this distinction. We're creating more "noise"
for end users if we end up adding all the "whoops" commits into the
%changelog.
On Sat, Jan 18, 2020 at 5:09 AM Richard W.M. Jones wrote:
>
> On Sat, Jan 18, 2020 at 12:02:08PM +, Richard W.M. Jones wrote:
> >
> > $ KRB5_TRACE=/dev/stderr koji -d hello
> > 2020-01-18 12:00:47,323 [DEBUG] koji: Opening new requests session
> > 2020-01-18 12:00:47,323 [DEBUG] koji: Opening
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
I work on a team at Red Hat with Kefu. He is very active with upstream
Ceph, though I have not watched his Fedora activity or lack thereof.
Is there a particular Fedora bug that you need Kefu to address?
- Ken
On Tue, Dec 17, 2019, 4:59 AM Vitaly Zaitsev via devel <
On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa wrote:
>
> On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer wrote:
> >
> > Hi folks,
> >
> > In EPEL 7 we have some packages with "python34" and "python36"
> > prefixes in their names. I guess this is a
Hi folks,
In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.
Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.
If I'm
On Tue, Oct 15, 2019 at 10:13 AM Adam Williamson
wrote:
> What's happening right now is the process of us trying something out
> and finding out where the problems are. That's what happens when you
> invent new stuff, it's harder than just carrying on doing the old
> stuff.
I agree Adam.
I
On Thu, Sep 26, 2019 at 7:11 AM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote:
> > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit :
> > > Here is what the vision we came to and that we would like to discuss:
> > >
> > > ○ Every changes to dist-git is
On Fri, Mar 22, 2019 at 1:08 PM Kevin Fenzi wrote:
>
> Fixed, and I looked and asked upstream and this is fixed in sigul 1.0.
>
> So, hopefully we won't have to keep doing this too much longer.
Thanks for digging into this!
___
devel mailing list --
I guess this depends on the status of the Apache httpd workers. Like are
they stuck in IO to the /mnt/koji scratch location, or something else?
Unfortunately it's not secure to publicly display Koji's in-flight HTTP
requests with mod_status, since the URLs contain the authenticated session
On Tue, Mar 5, 2019, 12:53 PM Miroslav Suchý wrote:
> Dne 04. 03. 19 v 17:34 Ken Dreyer napsal(a):
> >
> > I'm there with you Richard. I don't really get how I can get started
> building a module outside of the Fedora
> > infrastructure's system (Koji or Copr).
>
>
On Fri, Mar 1, 2019, 8:26 AM Richard Shaw wrote:
> Not replying to anyone in particular but just a nit for me...
>
> I've been a Fedora packager for probably 10 years now (need to check!) but
> I *STILL* don't really understand modules other than at a high level (it
> lets you use dependencies
On Fri, Mar 1, 2019, 3:20 PM Ben Cotton wrote:
>
> ** infrastructure: deploy the new version of bodhi and the new koji plugin
>
What's the new Koji plugin?
- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Fri, Feb 15, 2019 at 1:10 AM Matthias Runge wrote:
> With that, I'm looking for co-maintainers for python-cherrypy. The
> package is severely outdated and it seems there hasn't been any
> significant contribution to this over the past 4 years. I may have been
> too optimistic with my available
On Tue, Feb 19, 2019 at 10:47 AM Kevin Fenzi wrote:
>
> Sadly, not that I can find. ;(
Thanks for looking into it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code
On Mon, Feb 18, 2019 at 2:48 PM Kevin Fenzi wrote:
>
> On 2/18/19 12:56 PM, Kaleb Keithley wrote:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a
> >
> > Would someone please give them a kick?
>
> For some
On Tue, Feb 12, 2019 at 1:57 PM Felix Schwarz
wrote:
> "Upstream are releasing separate tarballs for Python 2 and Python 3 (from
> separate SVN branches), so this is a separate specfile for the Python 3
> branch."
>
> https://bugzilla.redhat.com/show_bug.cgi?id=579593
Thanks for that pointer
Hi python packagers,
Could someone please help me understand why we have python-cherrypy
and python3-cherrypy as two separate Fedora packages?
https://src.fedoraproject.org/rpms/python-cherrypy
https://src.fedoraproject.org/rpms/python3-cherrypy
It seems to me that "python3-cherrypy" should be
On Mon, Feb 11, 2019 at 11:38 AM Kevin Fenzi wrote:
>
> On 2/11/19 9:27 AM, Ken Dreyer wrote:
> > Hi EPEL folks,
> >
> > There are some packages in CentOS 7 that did not ship in the main RHEL
> > 7 Server product.
> >
> > Examples:
> >
> > pyt
Hi EPEL folks,
There are some packages in CentOS 7 that did not ship in the main RHEL
7 Server product.
Examples:
python-jwt http://access.redhat.com/errata/RHEA-2018:1032
python-adal https://access.redhat.com/errata/RHEA-2018:1042
This went into the "High Availability" and "Resilient Storage"
On Thu, Dec 13, 2018 at 4:14 AM Nicolas Mailhot
wrote:
> Not treating it as a community objective is how we got in a situation,
> where upstreams (including @rh upstreams) want nothing to do with rpms
> and Fedora, and invent their own packaging tech to bypass Linux
> distributions completely.
On Thu, Dec 6, 2018 at 6:12 AM Florian Weimer wrote:
> I'm worried that this kind of pointless work makes it hard to attract
> talent.
Florian, you might want to check out rdopkg.
https://github.com/softwarefactory-project/rdopkg . It's a bit like
fedpkg, in that it's a CLI with sub-commands.
On Tue, Nov 27, 2018 at 7:59 AM Owen Taylor wrote:
>
> A lot of discussion about improving the compose process seem to end up
> with a "reality check" - that ideas have already been tried but don't
> work because of requirements a) b) c) d). You can't have the pony, but
> maybe if a lot of effort
On Thu, Nov 15, 2018 at 6:09 AM Clement Verna wrote:
>
> On Thu, 15 Nov 2018 at 13:55, Petr Pisar wrote:
>> And unrelated question: The koji build NVR does not contain dist-git
>> name space. Does that mean there will be race conditions between rpms
>> and container builds when the NVR string
Wow, thanks Dusty!
This should definitely be the default for Pagure dist-git.
On Tue, Nov 20, 2018 at 7:25 AM Dusty Mabe wrote:
>
>
> I've certainly made the mistake of accidentally creating branches
> in dist-git and now being stuck with them because we can't delete
> them. Now that
On Thu, Nov 15, 2018 at 12:30 PM Colin Walters wrote:
>
> The doc does assume that the reader has some familiarity with
> the rpmdistro-gitoverlay project, yes. I'll look at tweaking that
> doc to mention looking at the toplevel README.
I looked at the top-level README but I gotta admit I was
On Thu, Nov 15, 2018 at 9:40 AM Colin Walters wrote:
> On Thu, Nov 15, 2018, at 10:57 AM, Matthew Miller wrote:
> > I think to do this we would need to have our own, controlled local git
> > mirror.
>
> This is step 2 in
>
On Thu, Nov 15, 2018 at 5:02 AM Florian Weimer wrote:
> Make it cheap to maintain branches. I expect that one what to achieve
> this would be to build directly out of Git, with synthesized release
> numbers and changelogs. This way, you can apply a lot of fixes to
> multiple branches without
On Tue, Nov 13, 2018 at 4:37 PM Matthew Miller wrote:
> But there are some good cases for a longer lifecycle. For one thing,
> this has been a really big blocker for getting Fedora shipped on
> hardware.
This is an interesting topic to me because I recently toured the
System76 factory here in
On Tue, Aug 21, 2018 at 4:50 AM, Petr Šplíchal wrote:
> Hi,
>
> as part of bringing upstream and downstream workflows related to
> testing one more step closer together and allow easier automation
> tools development and sharing between Fedora, Red Hat Enterprise
> Linux and other products, the
On Thu, Aug 16, 2018 at 9:28 AM, Miro Hrončok wrote:
>
> This has received no reply in ~2 weeks. Am I the only one who ask those
> questions?
I'm interested as well, I just have no idea about the answers.
- Ken
___
devel mailing list --
On Fri, Aug 10, 2018 at 3:16 AM, Daniel P. Berrangé wrote:
> ie, I'd love to be able todo "git show libvirt-4.5.0-1.fc28" from the cli
> to view a tag / commit from which the NEVR was made.
It would be cool to have Git tags in dist-git.
There is something very close that I use in the meantime,
On Wed, Jul 18, 2018 at 2:29 PM, Jason L Tibbitts III wrote:
>>>>>> "KD" == Ken Dreyer writes:
>
> KD> I've always thought it's the other way around, that EPEL moves
> KD> faster than RHEL,
>
> Well, what I said didn't contradict that, so... I gue
On Wed, Jul 18, 2018 at 9:36 AM, Jason L Tibbitts III wrote:
>> "RI" == Roman Iuvshyn writes:
>
> Maintainers are generally going to be very reluctant to update a package
> in EPEL without some pressing need. Not generally as reluctant as Red Hat
> would
> be for a package in RHEL7 proper
On Wed, Jul 11, 2018 at 11:39 AM, Ben Rosser wrote:
> We have been telling people for a while now that they don't "own"
> their packages. Making it easier for people to maintain their packages
> outside of dist-git and (effectively) ignore changes from
> proven-packagers seems to take us in the
On Tue, Jul 10, 2018 at 2:43 PM, Jason L Tibbitts III wrote:
> I guess that has to be another of those "nobody
> can touch this" packages.
Hey, c'mon, Ceph doesn't bite (that badly...)
Seriously though, we do maintain ceph.spec upstream in
http://github.com/ceph/ceph, in coordination with SUSE
On Thu, Jun 28, 2018 at 7:16 AM, Daniel Mach wrote:
> DNF shouldn't diverge from YUM just "because we can".
> We're fixing some obvious differences that weren't introduced for any good
> reason.
>
> There will be no special compat layer just a yum -> dnf symlink.
> If the compatibility is
On Fri, Jun 1, 2018 at 4:30 AM, Miroslav Suchý wrote:
> Do you have a use case for using ancient fedoras repos? What is better for
> you: to have ancient fedora repos or to have
> more architectures in Copr?
More arches for sure.
Even if multi-arch was not a consideration, it seems like a lot
Hi folks,
I had several Ruby and Perl packages in Fedora that I no longer
maintain any more.
I've assigned all these to the "orphan" ID in src.fedoraproject.org .
perl-Nagios-Plugin-WWW-Mechanize
perl-Net-INET6Glue
perl-Net-IP-Match-Regexp
perl-Test-Carp
rubygem-activerecord-nulldb-adapter
1 - 100 of 233 matches
Mail list logo
