Re: PSA: builds using forge macros with tags broken on rawhide
On Sun, Oct 14, 2018 at 7:21 PM Nicolas Mailhot
wrote:
>
> Le dimanche 14 octobre 2018 à 18:56 +0200, Fabio Valentini a écrit :
> >
> > You know that GitHub has supported the same thing for a long time?
> > The URL "
> > https://github.com/project/repo/archive/$REF/whatever-I-feel-like-1.0.tar.gz
> > "
> > will produce an archive of ref $REF (be it a tag, commit, or branch)
> > with the file name "whatever-I-feel-like-1.0.tar.gz". The forge macros
> > just don't make use of that feature,
>
> Actually, they do, that's the exact change you're complaining about
> here.
>
> And whatever-I-feel-like-1.0.tar.gz is useless because the topdir inside
> whatever-I-feel-like-1.0.tar.gz is definitively not whatever-I-feel-
> like-1.0, so you need to compute the actual topdir GitHub will generate
> and while you're at it the filename better match it or much %setup
> hilarity and packager unhappiness will ensue.
>
> And besides the code handle other things that GiHub that have changed
> behaviour over time.
>
> > but use the old "#anchor hack",
> > which not even the SourceURL packaging guidelines mention anymore.
>
> When the code was written it matched the guidelines whenever they
> produced working URLs (some guidelines didn’t). The guidelines and the
> code have been improved and fixed since. One reason the guidelines have
> been fixed is that the forge macro showed they were erroneous.
>
> > You know that github supports the same thing already, right? (Except
> > the "v" that's inserted before tags that don't match SemVer.)
>
> Ha ha ha. “except” v. And v does not have any simple rule, it is GiHub
> heuristic pile land, you have projects with some of their releases that
> uses v and others not, and GitHub can not even make up its mind in how
> to use it consistently for the same project release (it's in the url but
> not in the archive). I so wish GitHub would just give up on the whole v
> thing. Or do it all the time. But not sometimes yes, other times no.
>
> Since Google uses v in googlecode, and other hosting services do not,
> and GitHub tries to mirror everyone, their setup is doomed to fail as
> long as they do not standardise release tags git-upstream-side. By they
> still try to heuristic the problem away.
Ok. Let me backtrack. Since I don't assume that you broke a pile of
packages on purpose, let's focus on how to fix this.
Because right now, package builds prepared on fedora 27-29 will result
in failing koji builds for rawhide - and nobody should have to install
rawhide to be able to build packages.
Fabio
> > > — lobby git upstream to create a first-class release tag, with the
> > > same
> > > syntax for every hosting service and project, so I can kill the huge
> > > pile of heuristics that tries to guess what a specific project will
> > > use.
> > > An heuristic as everyone knows is something that works perfectly
> > > most of
> > > the time and fails miserably the rest of the time. And it is
> > > definitely
> > > *not* stable over time.
> >
> > Sure, upstream projects can always do stupid things ... but I don't
> > think that "stupid" should be the base-line here.
> >
> > > Alternatively, you can hardcode an url and archive name in your spec
> > > files, the result will be stable within the spec, but probably not
> > > work
> > > anymore whenever you need to bump the project version or commit.
> >
> > I've been doing exactly that for all my ~50 github based projects for
> > two years now, following this scheme:
> >
> > for stable releases:
> > - URL: https://github.com/project/%{name}
> > - Source0: %{url}/archive/%{version}/%{name}-%{version}.tar.gz
> > - %{autosetup}
> >
> > for snapshots (setting commit myself and computing shortcommit
> > automatically):
> > - URL: https://github.com/project/%{name}
> > - Source0: %{url}/archive/%{commit}/%{name}-%{shortcommit}.tar.gz
> > - %autosetup -n %{name}-%{commit}
> >
> > And this never broke. Not once.
> >
> > Which is why the SourceURL packaging guidelines recommend using
> > exactly these schemes.
> > (They already do so for github for a long time, and I updated them
> > some time ago for the new and better URLs that gitlab supports now.)
> >
> > But I've been trying to tell you this when the original forge macros
> > were introduced, and that has led nowhere either.
> >
> > So, I'll probably just gradually move back to using the Source URLs
> > for github/gitlab which are _actually documented_ in the Guidelines
> > and produce _stable_ results.
> >
> > Fabio
> >
> > > Regards,
> > >
> > > --
> > > Nicolas Mailhot
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.
Re: Fedora 30: Deprecating /etc/sysconf/nfs
On 10/12/18 2:54 PM, Stephen Gallagher wrote: > On Fri, Oct 12, 2018 at 2:48 PM Steve Dickson wrote: >> >> Hello, >> >> A few years back there was a movement the NFS community >> to consulate all nfs configuration into one file >> call /etc/nfs.conf... See nfs.conf(5) >> >> Maybe stupidly, I've maintain backwards compatibility >> for that last couple Fedora releases. I think it is >> time to go to the single file configuration, since >> the development on Fedora 29 is winding down and >> it's winding up for Fedora 30. >> >> On fresh rawhide installs /etc/sysconfig/nfs will still >> be installed but with direction to use /etc/nfs.conf >> >> If /etc/sysconfig/nfs does exists the configuration will >> *not* be overridden... but the systemd scripts will >> no longer use that file to do any configuration. >> >> We are working tool that will convert sysconfig/nfs >> configs into nfs.conf configs... It is not clear >> how I'm going to package it since it is something >> I do not want to support forever... but only time will tell. >> >> I'm not sure what will break, but pretty sure something >> is going to break. ;-) I'm steved on freenode and OFTC >> IRC channels... feel ping me... >> > > > Steve, please file a Change Proposal[1] for Fedora 30 to submit to > FESCo so we can help coordinate this. Done... https://fedoraproject.org/wiki/Changes/nfs.conf Is there anything else that need to happen? steved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: builds using forge macros with tags broken on rawhide
Le 2018-10-15 09:09, Fabio Valentini a écrit :
Because right now, package builds prepared on fedora 27-29 will result
in failing koji builds for rawhide - and nobody should have to install
rawhide to be able to build packages.
Well basically you can
1. use a rawhide vm on container of whatever to prepare your rawhide
srpms (but, as you noted, not cheap to setup)
2. use mock --shell to get a cheap rawhide buildroot srpm env (in theory
that works – not tested)
3. use a local rebuild of the rawhide redhat-rpm-config to match rawhide
behaviour (only takes changing dist definition in
/etc/macros.d/macros.dist to %{?distprefix}.fcxx
4. use a local backport of the code. You basicaly just need to insert
the following at line 251 or 252 of the macros.forge rawhide file
-- Workaround releases where distprefix is not used by default
local dist = rpm.expand("%{?dist}")
local edistprefix = rpm.expand(distprefix)
if (edistprefix ~= "") and (string.sub(dist, 1, #edistprefix) ~=
edistprefix) then
rpmmacros.explicitset("dist", "%{?distprefix}" .. dist,verbose)
end
5. ask to accelerate the backport to stable. I can prepare the backport
PR, but applying the PR is out of my hands
6. ask redhat-rpm-config maintainers to process
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35
since I have a backport already prepared and tested for this one
7. all of the above
I don’t know which solution best matches your workflow
And normally, you do stuff in and for rawhide first, and then backport,
but this is kind of a special case since the rawhide bit does not
usually extend to the srpm part, and Go packaging in Fedora is so
immature every release is pretty much a devel release from Go's POW, so
I understand where you're coming from.
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] PSA: System update fails when trying to remove rtkit-0.11-19.fc29
Recently a bug in rtkit packaging has been fixed, but the update *will fail* on all Fedora 29 pre-release installation that have rtkit installed (Workstation has it for sure). The details and the workaround is described here: https://fedoraproject.org/wiki/Common_F29_bugs#rtkit-update ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Intent to orphan / give to go-sig some unused leaf golang packages
Hi everybody,
I'm cleaning up my packages a bit, and I currently maintain some leaf
packages which aren't used by anything (or anything I use) at this
point in time.
The packages all have the go-sig as co-admin already, but I intend to
drop them from my radar completely. You know, cognitive burden and
stuff.
- golang-github-AudriusButkevicius-kcp-go
- golang-github-AudriusButkevicius-pfilter
- golang-github-calmh-luhn
- golang-github-ccding-go-stun
- golang-github-cznic-b
- golang-github-cznic-fileutil
- golang-github-cznic-golex
- golang-github-cznic-internal
- golang-github-cznic-lex
- golang-github-cznic-lexer
- golang-github-cznic-lldb
- golang-github-cznic-mathutil
- golang-github-cznic-ql
- golang-github-cznic-sortutil
- golang-github-cznic-strutil
- golang-github-cznic-zappy
- golang-github-edsrzf-mmap-go
- golang-github-klauspost-reedsolomon
- golang-github-remyoudompheng-bigfft
- golang-github-templexxx-cpufeat
- golang-github-templexxx-reedsolomon
- golang-github-templexxx-xor
- golang-github-tjfoc-gmsm
- golang-github-xtaci-kcp-go
- golang-github-xtaci-smux
- golang-github-zillode-notify
The length of this list of now unused leaf packages tells its own
story about the go ecosystem.
As far as I can tell, nothing in fedora depends on this set of
packages anymore, except some inter-dependencies between the packages
themselves.
All the packages are up-to-date with either the latest stable release
(where available) or the current git master branch, and all the
packages use the new golang packaging macros ("spec 3.0"). Tests are
run where available and pass (except where they don't).
If somebody wants to take over a package personally instead of it
being inherited by the go-sig group, I will give them the package
instead. I'll give up the remaining packages on Mon, 22 Oct. 2018.
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Monday's FESCo Meeting (2018-10-15)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2018-10-15 15:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = F30 Change: PHP 7.3 https://pagure.io/fesco/issue/1997 DECISION (+6, 0, -0) = Followups = #topic #1974 Problematic blocker for F29: dnf 'offline' module tracking .fesco 1974 https://pagure.io/fesco/issue/1974 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Re: 2018-10-15 @ 16:00 UTC - Fedora 29 Blocker Review Meeting
On Sat, Oct 13, 2018 at 8:13 PM Adam Williamson wrote: > ** NOTE ** I may not be able to run the meeting, as I'm going on > vacation that same Monday. If I'm not available, we really need someone > else to step up and run the meeting, as this is the last review meeting > before the go/no-go meeting which is on Thursday. Running the meeting > is easy, there is an SOP (linked below) and you can also refer to the > logs from previous meetings for tips. > Since when do we let you take time off? I can run the meeting if no one else has volunteered yet. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 29 Final Release Readiness meeting
Dear all, Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 29 Final Release Readiness meeting. This meeting will be held on Thursday, 2018-10-18 at 19:00 UTC. We will meet to make sure we are coordinated and ready for the Final release of Fedora 29. Please note that this meeting will be held even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may receive this message several times in order to open this meeting to the teams and to raise awareness, so hopefully more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. For more information, see https://fedoraproject.org/wiki/Release_Readiness_Meetings. View the meeting on Fedocal: https://apps.fedoraproject.org/calendar/Fedora%20release/2018/10/18/#m9380 -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Re: 2018-10-15 @ 16:00 UTC - Fedora 29 Blocker Review Meeting
On Mon, 2018-10-15 at 10:37 -0400, Ben Cotton wrote: > On Sat, Oct 13, 2018 at 8:13 PM Adam Williamson > wrote: > > > ** NOTE ** I may not be able to run the meeting, as I'm going on > > vacation that same Monday. If I'm not available, we really need someone > > else to step up and run the meeting, as this is the last review meeting > > before the go/no-go meeting which is on Thursday. Running the meeting > > is easy, there is an SOP (linked below) and you can also refer to the > > logs from previous meetings for tips. > > > Since when do we let you take time off? I can run the meeting if no > one else has volunteered yet. I'll be there. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 29 Final Release Readiness meeting
On Fri, Oct 12, 2018 at 11:30:29AM -0400, Ben Cotton wrote: > Dear all, > > Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 29 > Final Release Readiness meeting. This meeting will be held on Thursday, > 2018-10-18 at 19:00 UTC. > > We will meet to make sure we are coordinated and ready for the Final > release of Fedora 29. Please note that this meeting will be held even > if the release is delayed at the Go/No-Go meeting on the same day two > hours earlier. IIUC, we hold the readiness meeting just once for each release. It seems highly unlikely that we'll declare F29 go that Thursday, considering the number of open and proposed blockers. I think it'd make more sense to hold the readiness meeting either after every go/no-go meeting, or just once, but *after* F29 has been declared GO. What would be the procedure to make this change to the schedule? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Installation image layout
On Sun, Oct 14, 2018 at 02:21:47PM -0400, Neal Gompa wrote: > > Neal, any ideas who Marek could be a co-owner of the feature and help > > navigate the Fedora process? Maybe someone on the Anaconda or releng > > teams? > > > > Brian C. Lane from the Weldr team is probably the guy to work with on > this. He is the chief developer of Lorax, which is where > livemedia-creator comes from. I've CC'd him to this email. Thanks, Marek and I are already in touch :) As long as overlayfs can do what we need the bulk of the extra work needs to be done in anaconda-dracut. We may also want to make this switch an option for a bit, while we work out the details. -- Brian C. Lane (PST8PDT) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Schedule for Monday's FESCo Meeting (2018-10-15)
= #fedora-meeting-1: FESCO (2018-10-15) = Meeting started by contyk at 15:00:02 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-15/fesco.2018-10-15-15.00.log.html . Meeting summary --- * init process (contyk, 15:00:13) * #1974 Problematic blocker for F29: dnf 'offline' module tracking (contyk, 15:02:46) * LINK: https://pagure.io/fesco/issue/1974 (contyk, 15:02:52) * AGREED: drop blocker status on bug, document in release notes, common bugs and anywhere else we can (+7, 0, -0) (contyk, 15:21:05) * Next week's chair (contyk, 15:21:33) * ACTION: jforbes will chair next meeting (contyk, 15:23:32) * Open Floor (contyk, 15:23:43) Meeting ended at 15:43:14 UTC. Action Items * jforbes will chair next meeting Action Items, by person --- * jforbes * jforbes will chair next meeting People Present (lines said) --- * contyk (46) * bowlofeggs (30) * sgallagh (27) * bcotton (19) * zbyszek (18) * nirik (16) * zodbot (14) * jforbes (9) * tyll (1) * jsmith (0) * maxamillion (0) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Installation image layout
On Mon, Oct 15, 2018 at 08:30:39AM -0700, Brian C. Lane wrote: > On Sun, Oct 14, 2018 at 02:21:47PM -0400, Neal Gompa wrote: > > > Neal, any ideas who Marek could be a co-owner of the feature and help > > > navigate the Fedora process? Maybe someone on the Anaconda or releng > > > teams? > > > > > > > Brian C. Lane from the Weldr team is probably the guy to work with on > > this. He is the chief developer of Lorax, which is where > > livemedia-creator comes from. I've CC'd him to this email. > > > Thanks, Marek and I are already in touch :) As long as overlayfs can do > what we need the bulk of the extra work needs to be done in > anaconda-dracut. FWIW the change to anaconda-dracut to support _only_ overlayfs is quite small: https://github.com/marmarek/qubes-installer-qubes-os/commit/332be8e1e3e1006013772528078914f491d14c1f#diff-aa15299e3bf81c1e427c9d521d63778f And it drops dependency on dmsquash-live module. > We may also want to make this switch an option for a bit, while we work > out the details. Support for both layouts will be more tricky, because of the split between anaconda-dracut and dmsquash-live. Integrating (parts of?) the latter in the former would make it much easier. But IMO it's worth making it support both layouts, at least for now. Anyway, can somebody help me with change proposal? For example I'm not sure if this is "Self Contained" or "System Wide" Change, or what should specifically be listed in "Scope". If IRC would be more appropriate for such discussion, that's fine for me too. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Running a test from dist-git
On Thu, 11 Oct 2018 at 09:49, Richard W.M. Jones wrote: > > On Wed, Oct 10, 2018 at 11:26:01PM +0200, Miroslav Vadkerti wrote: > > Hi, > > > > sorry for the late response :( > > > > On Tue, Oct 2, 2018 at 9:42 AM Richard W.M. Jones wrote: > > > > > On Mon, Oct 01, 2018 at 11:26:59AM +0200, Miroslav Vadkerti wrote: > > > > For this time I rescheduled the run: > > > > > > > > > > > > > > > https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/850/pipeline > > > > > > It appears to have failed, but I've got no clue why. How do I see > > > the output of the command? > > > > > > > Ugh, logs are now gone. Which package were you testing? We can take a look > > what was the problem. > > https://src.fedoraproject.org/rpms/libguestfs > > The test is to run a single command (libguestfs-test-tool). This > command is already installed by the package, so there's no need for > any test harness or script. If the command fails (ie. exit code != 0) > then it's vital we see the complete output in order to diagnose the > problem. > > https://src.fedoraproject.org/rpms/libguestfs/blob/master/f/tests/tests.yml I've created pull request with fixed tests.yml file: https://src.fedoraproject.org/rpms/libguestfs/pull-request/4 In the pull request you would directly see link to the test results including the complete output of the test. Unfortunately there is currently issue with propagating results to Pagure: https://pagure.io/fedora-ci/general/issue/10 We are currently looking into this, it should be fixed soon. Meanwhile it's still possible to see results of the pipeline here: https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/activity/ https://fedoraproject.org/wiki/CI/Pipeline#Instances The latest libguestfs job is this: https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/detail/fedora-rawhide-pr-pipeline/459/pipeline Test output can be found under that "Artifact" tab: https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr-pipeline/459/artifact/package-tests/logs/PASS_libguestfs-test-tool.log Hope this helps. psss... > Ideally we'd want to run the test as root and non-root, but for now I > just had it run the test as root. > > > > I think it would be easier if we could just drop a shell script into > > > tests/ and have it run that and display the output. The current > > > system seems elaborately overengineered and I don't understand why. > > > > > > > Well, it was decided that we will use Ansible to wrap around our tests. Not > > my idea. I agree the results could be presented better though, even if the > > runner is Ansbile. We are preparing a dashboard to view the result of > > testing, to give a better user experience in the future. > > It wasn't very obvious to start off with, but it seems as if the > "standard test roles" are designed for the simple case of "just run a > script". However the use of YAML combined with the fact that you > can't easily run a test locally makes the whole thing very awkward. > (Also for some reason I didn't investigate yet, my copy of emacs > appears to hate YAML.) > > > If the pipeline goes through (i.e. tests were run), the pipeline ends up > > with Pass (test passed) or Unstable state (tests failed). If the test > > failed, the pipeline did not execute the testing. In the former case you > > should find logs in the Artifacts tab in Jenkins (test results are prefixed > > with PASS_ or FAIL_). If you encounter an error, we are here to help an > > investigate. > > Do the tests run if we submit scratch builds? AFAIK, testing on scratch builds is not currently enabled. > > Anyway feel free to submit a new build of libguestfs if you want to > see if you can make the test run. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 29 Final Release Readiness meeting
On Mon, Oct 15, 2018 at 03:13:01PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Oct 12, 2018 at 11:30:29AM -0400, Ben Cotton wrote: > > Dear all, > > > > Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 29 > > Final Release Readiness meeting. This meeting will be held on Thursday, > > 2018-10-18 at 19:00 UTC. > > > > We will meet to make sure we are coordinated and ready for the Final > > release of Fedora 29. Please note that this meeting will be held even > > if the release is delayed at the Go/No-Go meeting on the same day two > > hours earlier. > > IIUC, we hold the readiness meeting just once for each release. > It seems highly unlikely that we'll declare F29 go that Thursday, > considering the number of open and proposed blockers. I think it'd > make more sense to hold the readiness meeting either after every > go/no-go meeting, or just once, but *after* F29 has been declared GO. > What would be the procedure to make this change to the schedule? We discussed this during the FESCo meeting open floor. After listeing to counter-arguments, I withdraw my proposal. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering wrote: > On Di, 09.10.18 14:45, Anderson, Charles R (c...@wpi.edu) wrote: > > > > It would be nice if somebody managed to find where this is patched in > > > Debian. Because I somewhat doubt that they made this change without a > > > proper discussion. And Debian is very much server oriented. > > > > Can we not have the RPM package drop a file in /etc/security/limits.d > > to set the limit only when that package is installed? That way it > > only affects users of that package. > > That only affects stuff that goes through PAM (specifically, all PAM > stacks that include pam_limits.so). > > It is my intention to change this system wide, i.e. for system > services (which do not go through PAM) too. > Lennart, what is the path forward here? Should we pull in some security experts to give us recommendations on the best default value? Or are those conversations already happening somewhere else? Also, do you need any more information regarding the Wine esync use case, or has Zebediah provided sufficient data? Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On Mon, Oct 15, 2018 at 06:00:05PM +0200, Kamil Paral wrote: > On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering > wrote: > > > On Di, 09.10.18 14:45, Anderson, Charles R (c...@wpi.edu) wrote: > > > > > > It would be nice if somebody managed to find where this is patched in > > > > Debian. Because I somewhat doubt that they made this change without a > > > > proper discussion. And Debian is very much server oriented. > > > > > > Can we not have the RPM package drop a file in /etc/security/limits.d > > > to set the limit only when that package is installed? That way it > > > only affects users of that package. > > > > That only affects stuff that goes through PAM (specifically, all PAM > > stacks that include pam_limits.so). > > > > It is my intention to change this system wide, i.e. for system > > services (which do not go through PAM) too. > > > > Lennart, what is the path forward here? Should we pull in some security > experts to give us recommendations on the best default value? Or are those > conversations already happening somewhere else? Also, do you need any more > information regarding the Wine esync use case, or has Zebediah provided > sufficient data? It's being discussed in systemd upstream: https://github.com/systemd/systemd/pull/10244 It needs another round of review, but looks like it'll be merged soon. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Installation image layout
On Mon, Oct 15, 2018 at 05:52:29PM +0200, Marek Marczykowski-Górecki wrote: > Anyway, can somebody help me with change proposal? For example I'm not > sure if this is "Self Contained" or "System Wide" Change, or what should > specifically be listed in "Scope". If IRC would be more appropriate for > such discussion, that's fine for me too. I would suggest system-wide, since every edition and spin relies on the installer. "Scope" should cover everything you're changing, and everyone who is impacted in some way (whether they need to be directly involved, or are impacted and need to change something, or whether they just might like to be aware). -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On Mo, 15.10.18 18:00, Kamil Paral (kpa...@redhat.com) wrote: > On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering > wrote: > > > On Di, 09.10.18 14:45, Anderson, Charles R (c...@wpi.edu) wrote: > > > > > > It would be nice if somebody managed to find where this is patched in > > > > Debian. Because I somewhat doubt that they made this change without a > > > > proper discussion. And Debian is very much server oriented. > > > > > > Can we not have the RPM package drop a file in /etc/security/limits.d > > > to set the limit only when that package is installed? That way it > > > only affects users of that package. > > > > That only affects stuff that goes through PAM (specifically, all PAM > > stacks that include pam_limits.so). > > > > It is my intention to change this system wide, i.e. for system > > services (which do not go through PAM) too. > > > > Lennart, what is the path forward here? Should we pull in some security > experts to give us recommendations on the best default value? Or are those > conversations already happening somewhere else? Also, do you need any more > information regarding the Wine esync use case, or has Zebediah provided > sufficient data? Please follow the current state of this here: https://github.com/systemd/systemd/pull/10244 I have been discussing with some upstream kernel folks, and some more obstacles showed up (specifically, I was advised that we really should bump fs.file-max and fs.nr_open sysctls to their maximums these days, as these limits are not really useful anymore given that fd memory is properly tracked by memcg anyways these days), which I have now covered in the PR above. This is waiting for review, but should enter systemd upstream soon, and will then eventually trickle into Fedora. Lennart -- Lennart Poettering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: kdiff3 upgrade question
Thanks! Updated in rawhide. пн, 15 окт. 2018 г., 9:58 Miro Hrončok : > On 15.10.2018 08:38, Vascom wrote: > > Hi all. > > > > I need the advice of experienced maintainers. > > > > I found that kdiff3 in Fedora repo requires KDE 4 libs. But exist > > Qt5/KF5 version: > > https://github.com/KDE/kdiff3 > > > > I am received admin rights on this package and I want upgrade it. But > > old version has pure Qt4 subpackage kdiff3-qt and it is absent in KF5 > > version. > > > > My question: should I preserve kdiff3-qt (Qt4) or can drop it? > > Query what requires it: > > $ dnf repoquery --repo=rawhide --whatrequires kdiff3-qt > > And what buildrequires it: > > $ dnf repoquery --repo=rawhide-source --whatrequires kdiff3-qt > > I got nothing, so I'd drop it. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
R-tweenr license change
R-tweenr 1.0.0 has changed license from GPLv2+ and WTFPL to MIT and WTFPL. -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
