Re: Module Stream "Expansion"
On 9 August 2017 at 03:39, Ralph Bean wrote: > ## Solution: "Input" Modulemd Syntax Changes > > We’re going to extend the modulemd syntax to allow specifying multiple > dependencies in an "input" modulemd (the one that packagers modify). When > submitted to the build system, the module-build-service (MBS) will *expand* > these values under the hood, and submit **multiple** module builds to > itself based on the expansion. > > Here are some examples of modulemd files (maintained by humans) that might be > submitted to the MBS. > > Build on **all** active streams of the platform module. > dependencies: > buildrequires: > platform: [] On the Python SIG list, we've recently been discussing how we'd like the Python module streams to be defined for F28+ (since we don't want to make any major changes to the F27 plans at this late date), and we think we've spotted a potential problem with the described approach (depending on how "active stream" gets defined): it isn't clear how we would handle introducing new streams that we wanted to be explicitly opt-in only rather than opt-out. As a concrete example, the upstream Python 3.7 alpha & beta cycle will be running in parallel with the F28 development cycle. It would be beneficial to be able to create the corresponding module stream once the first alpha release is available, but we don't really want anyone else to implicitly start building against that stream until it hits the release candidate phase (as upstream's typical API and ABI stability guarantees don't apply until after the last beta release). Two potential solutions to that occurred to us: 1. Have a stream metadata attribute that controlled whether or not a branch was considered active for implicit dependency declarations (e.g. "active: no") 2. Replacing the idea of depending on active streams with the idea of depending on "stream tags", such that the stream metadata would include something like "tags: [active]", and you'd depend on all the streams in a stream tag the same way you currently depend on a single stream: "platform: active" Of the two, the second one seems more flexible, and has the added bonus of offering support for "stream aliases", since you'd be able to do things like "tags: [f26, f27]" (for example) to indicate that a stream was the default in particular versions of Fedora. For ease of adoption of stream expansion, there could also be a notion of making "active" an implied tag for any non-EOL stream, such that you'd have to opt-out explicitly to mark a stream *in*active: "tags: [-active]" Thoughts? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bugzilla auto-CC
Due to the sheer number of packages I have commit rights for (the whole inherited "gnome-sig" package list, https://src.fedoraproject.org/ shows 280 packages), I'll be marking all mails from the Fedora section of the Bugzilla as read. The infrastructure needs to be fixed instead of me doing busy work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr) >= 4.16
Dne 24.8.2017 v 16:46 Dridi Boukelmoune napsal(a): Hello, For some reason I fail to understand, a non-devel package is conflicting with a devel package :-/ According to dnf it's the only explicit conflict for the package: $ dnf repoquery --conflicts firefox-55.0.2-2.fc26.x86_64 pkgconfig(nspr) >= 4.16 Maybe someone confused Conflicts with BuildConflicts in the spec? Because there are several ways how to resolve the dependency and DNF chose from them one which is confusing for humans: See https://bugzilla.redhat.com/show_bug.cgi?id=1485881 Already Mirek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr) >= 4.16
On 08/24/2017 04:46 PM, Dridi Boukelmoune wrote: Hello, For some reason I fail to understand, a non-devel package is conflicting with a devel package :-/ According to dnf it's the only explicit conflict for the package: $ dnf repoquery --conflicts firefox-55.0.2-2.fc26.x86_64 pkgconfig(nspr) >= 4.16 Maybe someone confused Conflicts with BuildConflicts in the spec? You're right, I confused the Conflicts with BuildConflicts (didn't actually know that there's BuildConflicts). See https://bugzilla.redhat.com/show_bug.cgi?id=1484345#c11 ma. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Module Stream "Expansion"
On Wed, Aug 30, 2017 at 07:43:21PM +1000, Nick Coghlan wrote: > As a concrete example, the upstream Python 3.7 alpha & beta cycle will > be running in parallel with the F28 development cycle. It would be > beneficial to be able to create the corresponding module stream once > the first alpha release is available, but we don't really want anyone > else to implicitly start building against that stream until it hits > the release candidate phase (as upstream's typical API and ABI > stability guarantees don't apply until after the last beta release). I'm missing how this relates to the multiple targets problem here. Wouldn't you want that alpha (and eventually final) to be available across the different various bases? I'd think the solution is simply to mark your module with "Service Level: alpha" (and then we'd want some tooling where SL-alpha and SL-beta modules only show up for those who ask for them.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bugzilla auto-CC
On 30/08/17 00:50, mcatanz...@gnome.org wrote: Something changed yesterday and now the entire GNOME packager group is being automatically CCed to all GNOME-related bugs in Red Hat Bugzilla. There's no way to opt-out in Bugzilla preferences, at least not that I have found. What seems to have happened is that people in a group are now getting cced personally on the bug rather than the group getting cced. So BZ#1485653 opened on the 26th had nodejs-...@lists.fedoraproject.org added to the CC while BZ#1486721 opened just now had each member of the nodejs-sig group CCed on the bug. In one way it's good because it means you can remove yourself from the bug if you want, but it's also bad because you can't tell the difference between bugs in packages where you the primary maintainer and bugs in packagers where you just have group access. Certainly it seems like something which should have been discussed with the affected groups - note that it doesn't seem to be directly related to the migration to pagure as it only just changed in the last day or two. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr) >= 4.16
Hello, On Wed, Aug 30, 2017 at 12:33 PM, Miroslav Suchý wrote: > Because there are several ways how to resolve the dependency and DNF chose > from them one which is confusing for humans: > See > https://bugzilla.redhat.com/show_bug.cgi?id=1485881 > Already Non-optimal resolution is one problem, but not the reason why I brought this to the devel list instead of filing a bug. But this is interesting to know, thanks! On Wed, Aug 30, 2017 at 12:52 PM, Martin Stransky wrote: > On 08/24/2017 04:46 PM, Dridi Boukelmoune wrote: >> Maybe someone confused Conflicts with BuildConflicts in the spec? > > > You're right, I confused the Conflicts with BuildConflicts (didn't actually > know that there's BuildConflicts). See > https://bugzilla.redhat.com/show_bug.cgi?id=1484345#c11 OK, so this was not on purpose :) The problem I had was that nspr-devel installed prevented an upgrade of the nss package. Spurious blocking of nss updates is a red flag for me, and I'm wondering whether the tooling could catch that sort of things. Mainly, disapprove "normal" packages that conflict with devel packages (or for that matter other kinds of special packages like debuginfo). I don't think rpmlint would be a good candidate, because with a virtual provide like pkgconfig(nspr) it's not obvious it will resolve to a devel package (even though to my human eyes it's definitely screaming devel). So maybe a check could be implemented with Taskotron or something else, packages like golang libraries (source packages) seem to be consistently suffixed with -devel, I can't tell for other stacks. Are there guidelines covering that? Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bugzilla auto-CC
Sorry for any extra emails people are getting... many of us are at flock right now, but this wasn't intended, so something must have broken down. We will investigate as soon as we can. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
Hello Petr, On Thu, Aug 24, 2017 at 1:35 PM, Petr Stodulka wrote: > > > On 24.8.2017 08:04, Pavel Raiskup wrote: > > On Wednesday, August 23, 2017 1:46:46 PM CEST Miroslav Suchý wrote: > >> Do you use Copr for building packages for nightlies? For building > packages > >> before pull request is merged? > > > > Yes, not particulary me -- but I helped to guys in pgjdbc project to > setup CI: > > > > https://copr.fedorainfracloud.org/coprs/g/pgjdbc/pgjdbc-travis/ > > https://github.com/pgjdbc/pgjdbc/blob/master/packaging/ > rpm/fedora-image/copr-ci-git > > > >> Do you have your set up described somewhere? > > > > No, since it is too complicated. Tito is a burden for distro-agnostic > upstream. > > > > Since upstream had travis-ci already enabled, my plan was to generate > src.rpm in > > travis-ci and submit build into copr (together with other CI tasks). > > > > Two major problems: > > 1. Travis is (or was that time) debian/ubuntu only, so it is actually > not very > >convenient to install all the necessary tooling there; so the > work-around > >was to use Fedora docker-image and that image is pulled in for each > CI run. > > > > 2. You need to store your copr credentials into git. You can cipher > that, but > >at least it is not convenient to store *your own* copr authentication > token > >into git repo, because always at least other git committers can > decipher it. > >You also need to re-generate your API token twice a year (it means > you need > >to bother the upstream with "useless" commits, but the worst thing is > that > >you need to regularly go back and pay attention to fixing the CI). > > > > Being able to specify (a) scm repo, (b) build deps and (c) any (turing > complete) > > script within the git repo (to generate the sources) would make setting > up the > > CI a trivial task. > > +1 > > That is something that could help us definitely too. Nowadays we have > scripts for > packaging in Jenkins, that run tests and prepare SRPM for the COPR, that > requires > in addition changes in upstream repository itself (e.g. public spec file > as part > of the repository). More convenient would be (not only for our team, but > for me too > as packager) > > a) option to provide script in COPR, that will prepare sources, patches, > modified SPEC file, ... on the COPR side. The script would be processed > for example > when I sent request to COPR for specific repository, with whatever data > that will > be processed by the script (e.g. commit hash, branch, PR number). > > b) store the specfile into the COPR repository, so it could be used by the > script >and it will not be required to be part of the upstream repository > (usually the >SPEC is not part of the upstream repo or we want different spec than > upstream >provides) > > I found now that in COPR is something that b) describes, but I am not sure > that > it is same. Still, own script that would prepare sources for COPR builds > is the > most missing feature for me. > > We are considering the options here and so far the most convenient method (at least from the implementation point of view) seems to be to automatically call `make srpm` command in the source git repo if user selects `make srpm` as a srpm generator method for his (or her) SCM project (this will be a select field in UI and also it will be a build parameter available in our future API). That means it would be a custom script placed inside a Makefile under srpm goal. Custom packages needed for this operation could be specified in minimal buildroot of the given chroot (in chroot settings). We will probably also add a field to differentiate between srpm buildroot packages and rpm buildroot packages and also make this setting available across all project chroots. Would this cover and satisfy your needs? I would personally really like if we made it possible for you to use COPR solely. COPR will soon become _very_ powerful tool. > > > > > Pavel > > > >> What is the name of your > >> project? > >> > >> Please let me know. Either here or via private reply. > >> It will help me to understand your use of Copr and to make Copr better. > >> > >> Thanks in advance. > >> > >> Miroslav Suchy > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > -- > Petr Stodulka > Core Services (In-place upgrades and migrations) > IRC nicks: pstodulk, skytak > Red Hat > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe
Re: CI projects in Copr
Hello Martin, On Wed, Aug 23, 2017 at 2:02 PM, Martin Sehnoutka wrote: > Hi, > > I'm using Copr for build on commit for dnssec-trigger project: > https://github.com/InfrastructureServices/dnssec-trigger-fedora > It's using tito. > > But I'm looking for a different way of doing this. Especially when I > work on some upstream project and I don't want to force them to include > tito. Anyway I didn't have time to check other possible solutions to > this problem. > Thanks for such a great feedback. We would like to provide several options for srpm generation out of a SCM (Git/SVN) repo: tito, rpkg, and custom (where custom could be done by e.g. calling `make srpm` command in the repo). Both rpkg and custom will be very "light-weight". rpkg will need .spec file present in the repository, with "custom" you can do anything you want. We should have this solution quite soon so I can keep you informed. > > Regards, > Martin > > On 08/23/2017 01:46 PM, Miroslav Suchý wrote: > > Hi, > > I am gathering informations about various use of CI with Copr. Do you > > use Copr for building packages for nightlies? For building packages > > before pull request is merged? Do you have your set up described > > somewhere? What is the name of your project? > > > > Please let me know. Either here or via private reply. > > It will help me to understand your use of Copr and to make Copr better. > > > > Thanks in advance. > > > > Miroslav Suchy > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > -- > Martin Sehnoutka | Associate Software Engineer > PGP: 5FD64AF5 > UTC+1 (CET) > RED HAT | TRIED. TESTED. TRUSTED. > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bugzilla auto-CC
On 08/30/2017 09:47 AM, Kevin Fenzi wrote: > Sorry for any extra emails people are getting... many of us are at flock > right now, but this wasn't intended, so something must have broken down. > We will investigate as soon as we can. I have filed: https://pagure.io/fedora-infrastructure/issue/6315 to track this issue and Ralph is investigating. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bugzilla auto-CC
Found it. The fix needs to land in pagure itself. See the infra ticket for more details. https://pagure.io/fedora-infrastructure/issue/6315 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bugzilla auto-CC
Thanks for the speedy response! Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Can't upgrade to Fedora 27 via dnf system-upgrade
Hi, it seems the upgrade path to Fedora 27 via dnf system-upgrade is currently broken. Everytime I try to upgrade I get the following errors: > Problem 1: package grub2-1:2.02-0.40.fc26.x86_64 requires grub2- > tools = 1:2.02-0.40.fc26, but none of the providers can be installed > - grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a > distupgrade repository > - problem with installed package grub2-1:2.02-0.40.fc26.x86_64 > Problem 2: package rpmfusion-free-release-26-1.noarch requires > system-release(26), but none of the providers can be installed > - fedora-release-26-1.noarch does not belong to a distupgrade > repository > - problem with installed package rpmfusion-free-release-26-1.noarch > Problem 3: package fedora-release-26-1.noarch requires fedora- > repos(26) >= 1, but none of the providers can be installed > - package rpmfusion-nonfree-release-26-1.noarch requires system- > release(26), but none of the providers can be installed > - fedora-repos-26-1.noarch does not belong to a distupgrade > repository > - problem with installed package rpmfusion-nonfree-release-26- > 1.noarch > Problem 4: package fwupdate-libs-9-0.2.fc27.x86_64 requires shim, > but none of the providers can be installed > - problem with installed package fwupdate-libs-8-4.fc26.x86_64 > - shim-0.8-10.x86_64 does not belong to a distupgrade repository > - fwupdate-libs-8-4.fc26.x86_64 does not belong to a distupgrade > repository > Problem 5: problem with installed package abrt-java-connector-1.1.0- > 8.fc24.x86_64 > - package abrt-java-connector-1.1.0-8.fc24.x86_64 requires > librpm.so.7()(64bit), but none of the providers can be installed > - rpm-libs-4.13.0.1-7.fc26.x86_64 does not belong to a distupgrade > repository Is there a way to upgrade with dnf system-upgrade or do I need to wait until Fedora 27 beta? -- Regards, Heiko Adams signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bugzilla auto-CC
:) Pierre was able to hotfix pagure prod with the watchers fix. I confirmed that the sync script worked correctly on the nodejs-accepts package - it set the default cc list to the nodejs sig mailing list stored in FAS. I started a full run to reset all projects, but it takes quite a while to complete. Should be all fixed up when that's done. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Can't upgrade to Fedora 27 via dnf system-upgrade
2017-08-30 19:01 GMT+02:00 Heiko Adams : > Hi, > it seems the upgrade path to Fedora 27 via dnf system-upgrade is > currently broken. Everytime I try to upgrade I get the following > errors: There are lot of different errors, but for what rpmfusion is concerned, you should probably manually upgrade the rpmfusion-*-release package to 27 (looking at the Configuration page). This is because system-upgrade assume the repository path for 27 can be derived from the 26 repos which is sometime not true. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Can't upgrade to Fedora 27 via dnf system-upgrade
On Wed, Aug 30, 2017 at 07:01:18PM +0200, Heiko Adams wrote: > it seems the upgrade path to Fedora 27 via dnf system-upgrade is > currently broken. Everytime I try to upgrade I get the following > errors: > > Problem 1: package grub2-1:2.02-0.40.fc26.x86_64 requires grub2- > > tools = 1:2.02-0.40.fc26, but none of the providers can be installed > > - grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a > > distupgrade repository We're not getting successful F27 composes right now. This is being worked on, but I'm not sure how long it will be until it gets into good shape. You shouldn't need to wait until beta, but it may be a couple of days. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Can't upgrade to Fedora 27 via dnf system-upgrade
I had played hardly for about 48 hours until I run from another terminal (Tilix) the following command, as root, of course: 'dnf upgrade repository-packages --releasever=27' - just this. The difference between GNOME Terminal 3.24.3 and Tilix is that Tilix doesn't stop on every install/upgrade/erasing package error, compared to Gnome Terminal, which is stops the entire command operation, when errors on the way occurred. I may say, that it is not the command, that I finally have configured did the main system upgrade, but the use of Terminal, that don't stop on errors, like the Gnome Terminal. This what I know, that had made the most of my system. Now I'll reboot and see what else should I do. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OCaml / aarch64 / binutils / coq mess
On Tue, 29 Aug 2017 14:51:49 +0100 "Richard W.M. Jones" wrote: > OCaml 4.05 was added to Fedora 27+ recently. Unfortunately, on > aarch64 only, it interacts badly with a change made in binutils 2.29 > which tightens up the rules on relocations for PC-relative addresses. > More details: > > https://caml.inria.fr/mantis/view.php?id=7585detailed discussion > https://github.com/ocaml/ocaml/pull/1268 partial solution > https://sourceware.org/ml/binutils/2017-06/msg00171.html binutils change > > This only affects dynamic loading of OCaml modules on aarch64, and in > particular it only affects the Coq theorem prover. This package has a > number of dependencies, so it affects several other packages too. I > believe the complete list is: > > - coq Theorem prover > - frama-c Framework for source code analysis of C software > - gappalib-coq Coq support library for gappa > - why Software verification platform > > I tried very hard to modify the OCaml aarch64 code generator to make > this work, but it seems as if the OCaml front end compiler doesn't > provide enough information for us to know if a particular symbol will > be used outside a module (it just assumes that all non-private symbols > can be used this way). Or something. Anyway I couldn't work out how > to fix it. > > So ... I don't know what to do here, but I guess possible options > include: > > (1) Continue having broken dependencies for the affected packages on > aarch64 for a bit and see if upstream come up with anything. I would lean to that "solution" > > (2) ‘ExcludeArch: aarch64’ on coq and its dependencies. We would of > course file the relavent ExcludeArch bugs. The thing that stops me > doing this is that we're nowhere nearer to having a fix, so it just > punts the problem, plus aarch64 is an important target and Coq is an > important package. > > (3) Disable the problematic coq modules. I'm not clear if they are > necessary however, since I've only used Coq as an end user, I've never > delved into how it works. > > (4) Back out the binutils change? I guess it was made for good > reasons even though it breaks everything. Also it would be a > downstream change which is bad for Fedora, and we'd probably need to > mass-rebuild everything which is even worse. > > (5) Your Plan Here. I would file a bug against binutils to get attention from the maintainer (nickc), not sure he is monitoring this list. Dan > > Suggestions? > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OCaml / aarch64 / binutils / coq mess
On Wed, Aug 30, 2017 at 2:57 PM, Dan Horák wrote: > On Tue, 29 Aug 2017 14:51:49 +0100 > "Richard W.M. Jones" wrote: > >> (1) Continue having broken dependencies for the affected packages on >> aarch64 for a bit and see if upstream come up with anything. > > I would lean to that "solution" Me, too. Let's give upstream a chance to fix the problem. BTW, most of the packages that sit on top of coq have new versions available, so when this is fixed, I will want to update the other packages anyway. If you could let me know when a fix for this issue is available, I will take care of building everything else. >> (2) ‘ExcludeArch: aarch64’ on coq and its dependencies. We would of >> course file the relavent ExcludeArch bugs. The thing that stops me >> doing this is that we're nowhere nearer to having a fix, so it just >> punts the problem, plus aarch64 is an important target and Coq is an >> important package. I'd say we should do this only if we are getting close to F27 beta (maybe final) freeze and no upstream fix is in sight. In that case, we'll want to have the rebuilt packages available for other architectures. >> (3) Disable the problematic coq modules. I'm not clear if they are >> necessary however, since I've only used Coq as an end user, I've never >> delved into how it works. Which ones are problematic? All of them? -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Self Introduction: Duck
Quack, I'm a duck from DuckLand, and during my stay on shadow Earth I found fun do do some packaging. I've been a Debian developer since 2005 but I also use CentOS and Fedora so why not contribute here too. I've been working for a long time around Free softwares and I'm now working at Red Hat in the Open Source and Standards (OSAS) team. My first contribution is packaging PostSRSd: https://bugzilla.redhat.com/show_bug.cgi?id=1471056 Thanks Robert-André Mauchin for the review. I'd be happy if someone would kindly sponsor me. \_o< signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
On Wednesday, August 30, 2017 5:18:39 PM CEST Michal Novotny wrote: > We are considering the options here and so far the most convenient method (at > least from the implementation point of view) seems to be to automatically call > `make srpm` command in the source git repo if user selects `make srpm` as a > srpm generator method I'm curious why you insist on 'make srpm'; that sounds like you try to push the copr users somewhere, to "standardize something". Please allow specifying custom script, relatively placed in the git repository. That's exactly the same thing, but users don't have to create Makefile "because copr ..." -- users just can use what they already have. > for his (or her) SCM project (this will be a select > field in UI and also it will be a build parameter available in our future > API). That means it would be a custom script > placed inside a Makefile under srpm goal. Custom packages needed for this > operation could be > specified in minimal buildroot of the given chroot (in chroot settings). > > We will probably also add a field to differentiate between srpm buildroot > packages and rpm buildroot packages and also make this setting available > across all project chroots. Thanks for this! Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
