Re: Orphaned: elementry, evas-generic-loaders
On Thu, Sep 8, 2016 at 5:34 AM, Christopher Meng wrote:
>
>
> On Thursday, September 8, 2016, Kevin Kofler wrote:
>>
>> I wrote:
>> > <= 1.17.0 should still match that, I think (because there's no -Release
>> > in
>> > there), but still, <= Obsoletes are usually a bad idea (< is safer).
>>
>> PS: To be clear, I would use either:
>> Obsoletes: evas-generic-loaders < 1.17.1
>> if I am sure that the version will never go back to 1.17.0, or:
>> Obsoletes: evas-generic-loaders < 1.17.0-100
>> to be safe. (It should catch all current and future EVRs on the branches
>> that still ship the old version (in the worst case, use Release: 99.1,
>> 99.2,
>> etc.), but still allow you to bring back evas-generic-loaders-1.17.0 if
>> needed.)
>
>
> 100 is not enough at all, even . Since efl has higher version, just use
> proper macros.
>
> Obsoletes: evas-generic-loaders <= %{version}-%{release}
This is bad idea though.
>
>
> Obsoletes: evas-generic-loaders%{?_isa} <= %{version}-%{release}
As I wrote week ago to ML, %{?_isa} is virtual provides and it will
never work for Obsoletes.
>
>
>
> --
>
> Yours sincerely,
> Christopher Meng
>
> http://cicku.me
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaned: elementry, evas-generic-loaders
Kevin, yeah, you are right. It will work as there is no -Release.
Didn't see this before.
On Thu, Sep 8, 2016 at 12:59 AM, Kevin Kofler wrote:
> Igor Gnatenko wrote:
>> +Obsoletes: evas-generic-loaders <= 1.17.0
>>
>> This is basically wrong because current version is 1.17.0-5%{?dist}.
>
> <= 1.17.0 should still match that, I think (because there's no -Release in
> there), but still, <= Obsoletes are usually a bad idea (< is safer).
>
> Kevin Kofler
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Unplanned ABI break in http-parser on F23
Recently, I updated http-parser from a 2.1 git prerelease snapshot to the latest stable release 2.7.1 in all supported Fedora branches. I didn't anticipate any issues because 1) the soname didn't change and 2) the project upstream uses semantic versioning, which should imply that 2.7.x should be fully backwards-compatible with 2.0. Unfortunately, it looks like this is not perfectly true[1]. My suspicion is that the git snapshot my predecessor selected was not perfectly compatible (which was likely fixed before the official 2.1 release happened). However, so far it *does* appear that a trivial rebuild is all that is needed to get things working again in client software. There are two approaches that I can take: 1) I can bump epoch and revert the version of http-parser in F23 back to the git snapshot. 2) I can fire off a rebuild of the affected packages within Fedora, which appear to be: * libgit2 * mesos * nodejs * ocserv (already rebuilt since) * sssd (already rebuilt since) Given how few packages this appears to affect, I'm leaning towards taking option 2. I strongly suspect that whichever component was broken is not heavily-used, else I imagine I'd be hearing about considerably greater breakage (particularly in nodejs) I was comfortable pushing it in F23 because the SSSD team tested that it didn't break their code and provided Bodhi karma to that effect. I'm aware that option 2) is technically in violation of the stable updates policy, however given the age of the older snapshot and the fact that it was clearly not properly compatible with the 2.x release series, I feel that if I had to provide any patches, they would be beyond my ability to backport. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1374081 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
>>Sounds like this scope would warrant a Change? > > The components should be already prepared for DNF-2 and the changes > are not huge. There's the FESCO ticket [5]. If it is not accepted then > we will submit a Change. Actually, the preferred approach would be for this to come to FESCo *as* a Change. Mostly because the Change Process requires you to explain the situation fully and establish a contingency plan. >>> >>> Completely agree, we (rel-eng and I'm sure others) don't want to find >>> out one day everything is broken due to this change and the compose is >>> up the spout. Core components such as dnf need to follow the process >>> properly and communicate far and wide so people are aware of the >>> changes in flight that could affect everything from builds to users >>> updating. >> >> FESCo requested that a System Wide Change should be submitted for this. >> >> Regards, >> Dominik > > Ok, we will file a System Wide Change then. Yet it's not filed here [1] as a system wide change. Why? Given it's the updates system there, at least IMO, needs to be full contingency plans etc. Sorry, the history of the dnf team not breaking stuff even on small bumps gives me little faith this will be smooth. [1] https://fedoraproject.org/wiki/Changes/DNF-2.0 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Orphaned Packages in rawhide (2016-09-08)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package(co)maintainers Status Change === and orphan, s4504kr 5 weeks ago avra orphan, musolinoa 6 weeks ago beorphan, cicku, till 0 weeks ago cvsclient orphan, java-sig, mizdebsk, 14 weeks ago msrb dbmailorphan, bjohnson10 weeks ago docsis-config-encoder orphan, raphgro 0 weeks ago dwatchorphan, bjohnson10 weeks ago firecontrol orphan, dajt, jwilson 5 weeks ago freeradius-client orphan, nmav18 weeks ago ghc-editline orphan, haskell-sig, s4504kr5 weeks ago ghc-primesorphan, haskell-sig, s4504kr5 weeks ago glusterfs-hadoop orphan, lalatendu 13 weeks ago gnome-password-generator orphan, rishi 6 weeks ago gnustep-back orphan, s4504kr 5 weeks ago gnustep-examples orphan, s4504kr 5 weeks ago gnustep-gui orphan, s4504kr 5 weeks ago gorm orphan, s4504kr 5 weeks ago gresolver orphan, s4504kr 5 weeks ago i7z orphan, fantom, raphgro 0 weeks ago js-jquery-migrate orphan, group::nodejs-sig, 5 weeks ago jamielinux, patches kaya orphan, s4504kr 5 weeks ago latex2emf orphan, alexlan 5 weeks ago libsieve orphan, bjohnson10 weeks ago libzdborphan, bjohnson, cicku 10 weeks ago luma orphan, s4504kr 5 weeks ago maniadriveorphan, jwrdegoede 9 weeks ago mdp orphan, raphgro 0 weeks ago media-explorerorphan, hadess 1 weeks ago netmonitororphan, fab, tuxbrewr 7 weeks ago open-cobolorphan, s4504kr 5 weeks ago phpMemcachedAdmin orphan 11 weeks ago picprog orphan, musolinoa 6 weeks ago polipoorphan, bjohnson, jcp 10 weeks ago powerman orphan, tuxbrewr29 weeks ago psgml orphan, alexlan 5 weeks ago pypop orphan, alexlan 5 weeks ago python-javaobjorphan, raphgro 0 weeks ago queuegraphorphan, bjohnson10 weeks ago rhncfgorphan 12 weeks ago snobolorphan, s4504kr 5 weeks ago suck orphan, s4504kr 5 weeks ago system-config-dateorphan, nphilipp2 weeks ago system-config-date-docs orphan, nphilipp2 weeks ago system-config-network orphan, nphilipp2 weeks ago system-config-nfs orphan, nphilipp2 weeks ago system-config-nfs-docsorphan, nphilipp2 weeks ago system-config-samba orphan, nphilipp2 weeks ago system-config-samba-docs orphan, nphilipp2 weeks ago system-config-servicesorphan, nphilipp2 weeks ago system-config-services-docs orphan, nphilipp2 weeks ago system-config-users orphan, nphilipp2 weeks ago system-config-users-docs orphan, nphilipp2 weeks ago thttpdorphan, fab, thias 7 weeks ago xfce-bluetooth
Orphaned Packages in branched (2016-09-08)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package(co)maintainers Status Change === and orphan, s4504kr 5 weeks ago avra orphan, musolinoa 6 weeks ago beorphan, cicku, till 0 weeks ago cvsclient orphan, java-sig, mizdebsk, 14 weeks ago msrb dbmailorphan, bjohnson10 weeks ago docsis-config-encoder orphan, raphgro 0 weeks ago dwatchorphan, bjohnson10 weeks ago firecontrol orphan, dajt, jwilson 5 weeks ago freeradius-client orphan, nmav18 weeks ago ghc-editline orphan, haskell-sig, s4504kr5 weeks ago ghc-primesorphan, haskell-sig, s4504kr5 weeks ago glusterfs-hadoop orphan, lalatendu 13 weeks ago gnustep-back orphan, s4504kr 5 weeks ago gnustep-examples orphan, s4504kr 5 weeks ago gnustep-gui orphan, s4504kr 5 weeks ago gorm orphan, s4504kr 5 weeks ago gresolver orphan, s4504kr 5 weeks ago i7z orphan, fantom, raphgro 0 weeks ago jpype orphan, raphgro 0 weeks ago js-jquery-migrate orphan, group::nodejs-sig, 5 weeks ago jamielinux, patches kaya orphan, s4504kr 5 weeks ago latex2emf orphan, alexlan 5 weeks ago libsieve orphan, bjohnson10 weeks ago libzdborphan, bjohnson, cicku 10 weeks ago luma orphan, s4504kr 5 weeks ago maniadriveorphan, jwrdegoede 9 weeks ago mdp orphan, raphgro 0 weeks ago media-explorerorphan, hadess 1 weeks ago netmonitororphan, fab, tuxbrewr 7 weeks ago open-cobolorphan, s4504kr 5 weeks ago phpMemcachedAdmin orphan 11 weeks ago picprog orphan, musolinoa 6 weeks ago polipoorphan, bjohnson, jcp 10 weeks ago powerman orphan, tuxbrewr29 weeks ago psgml orphan, alexlan 5 weeks ago pypop orphan, alexlan 5 weeks ago python-javaobjorphan, raphgro 0 weeks ago queuegraphorphan, bjohnson10 weeks ago rhncfgorphan 12 weeks ago snobolorphan, s4504kr 5 weeks ago suck orphan, s4504kr 5 weeks ago system-config-dateorphan, nphilipp2 weeks ago system-config-date-docs orphan, nphilipp2 weeks ago system-config-network orphan, nphilipp2 weeks ago system-config-nfs orphan, nphilipp2 weeks ago system-config-nfs-docsorphan, nphilipp2 weeks ago system-config-samba orphan, nphilipp2 weeks ago system-config-samba-docs orphan, nphilipp2 weeks ago system-config-servicesorphan, nphilipp2 weeks ago system-config-services-docs orphan, nphilipp2 weeks ago system-config-users orphan, nphilipp2 weeks ago system-config-users-docs orphan, nphilipp2 weeks ago thttpdorphan, fab, thias 7 weeks ago xfce-bluetooth
Re: Unplanned ABI break in http-parser on F23
On Thu, Sep 8, 2016 at 11:21 AM, Stephen Gallagher wrote: > Recently, I updated http-parser from a 2.1 git prerelease snapshot to the > latest > stable release 2.7.1 in all supported Fedora branches. I didn't anticipate any > issues because 1) the soname didn't change and 2) the project upstream uses > semantic versioning, which should imply that 2.7.x should be fully > backwards-compatible with 2.0. > > Unfortunately, it looks like this is not perfectly true[1]. My suspicion is > that > the git snapshot my predecessor selected was not perfectly compatible (which > was > likely fixed before the official 2.1 release happened). > > However, so far it *does* appear that a trivial rebuild is all that is needed > to > get things working again in client software. > > There are two approaches that I can take: > > 1) I can bump epoch and revert the version of http-parser in F23 back to the > git > snapshot. You'd need epochs on all releases to ensure upgrade paths. > 2) I can fire off a rebuild of the affected packages within Fedora, which > appear > to be: > > * libgit2 > * mesos > * nodejs > * ocserv (already rebuilt since) > * sssd (already rebuilt since) > > > Given how few packages this appears to affect, I'm leaning towards taking > option > 2. I strongly suspect that whichever component was broken is not heavily-used, > else I imagine I'd be hearing about considerably greater breakage > (particularly > in nodejs) > > I was comfortable pushing it in F23 because the SSSD team tested that it > didn't > break their code and provided Bodhi karma to that effect. > > > > > I'm aware that option 2) is technically in violation of the stable updates > policy, however given the age of the older snapshot and the fact that it was > clearly not properly compatible with the 2.x release series, I feel that if I > had to provide any patches, they would be beyond my ability to backport. I think 2) makes sense in this case. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On 09/08/2016 01:05 PM, Peter Robinson wrote: Sounds like this scope would warrant a Change? The components should be already prepared for DNF-2 and the changes are not huge. There's the FESCO ticket [5]. If it is not accepted then we will submit a Change. Actually, the preferred approach would be for this to come to FESCo *as* a Change. Mostly because the Change Process requires you to explain the situation fully and establish a contingency plan. Completely agree, we (rel-eng and I'm sure others) don't want to find out one day everything is broken due to this change and the compose is up the spout. Core components such as dnf need to follow the process properly and communicate far and wide so people are aware of the changes in flight that could affect everything from builds to users updating. FESCo requested that a System Wide Change should be submitted for this. Regards, Dominik Ok, we will file a System Wide Change then. Yet it's not filed here [1] as a system wide change. Why? The change proposal is in WIP state. Given it's the updates system there, at least IMO, needs to be full contingency plans etc. Sorry, the history of the dnf team not breaking stuff even on small bumps gives me little faith this will be smooth. The internal DNF testing stack undergone radical improvements during the last year. Core DNF functionality is now covered by functional tests. Therefore, we expect only minor issues with adoption of 2.0. Michal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On 09/08/2016 07:05 AM, Peter Robinson wrote: >>>Sounds like this scope would warrant a Change? >> >> The components should be already prepared for DNF-2 and the changes >> are not huge. There's the FESCO ticket [5]. If it is not accepted then >> we will submit a Change. > > Actually, the preferred approach would be for this to come to FESCo *as* > a > Change. Mostly because the Change Process requires you to explain the > situation > fully and establish a contingency plan. Completely agree, we (rel-eng and I'm sure others) don't want to find out one day everything is broken due to this change and the compose is up the spout. Core components such as dnf need to follow the process properly and communicate far and wide so people are aware of the changes in flight that could affect everything from builds to users updating. >>> >>> FESCo requested that a System Wide Change should be submitted for this. >>> >>> Regards, >>> Dominik >> >> Ok, we will file a System Wide Change then. > > Yet it's not filed here [1] as a system wide change. Why? Given it's > the updates system there, at least IMO, needs to be full contingency > plans etc. Sorry, the history of the dnf team not breaking stuff even > on small bumps gives me little faith this will be smooth. > > [1] https://fedoraproject.org/wiki/Changes/DNF-2.0 Give them a little time, Peter. It's still marked as ChangePageIncomplete :) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On Thursday, 08 September 2016 at 13:37, Michal Luscon wrote: > On 09/08/2016 01:05 PM, Peter Robinson wrote: [...] > > Given it's the updates system there, at least IMO, needs to be full > > contingency > > plans etc. Sorry, the history of the dnf team not breaking stuff even > > on small bumps gives me little faith this will be smooth. > The internal DNF testing stack undergone radical improvements during the > last year. Core DNF functionality is now covered by functional tests. > Therefore, we expect only minor issues with adoption of 2.0. Those are famous last word, you know. ;) It's better to have a solid contingency plan and never use it than not have it and be forced to scramble in the unlikely case something goes wrong because you "expected only minor issues". Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Last DNF-1 version, DNF-2 coming to rawhide
On 09/08/2016 01:48 PM, Dominik 'Rathann' Mierzejewski wrote: On Thursday, 08 September 2016 at 13:37, Michal Luscon wrote: On 09/08/2016 01:05 PM, Peter Robinson wrote: [...] Given it's the updates system there, at least IMO, needs to be full contingency plans etc. Sorry, the history of the dnf team not breaking stuff even on small bumps gives me little faith this will be smooth. The internal DNF testing stack undergone radical improvements during the last year. Core DNF functionality is now covered by functional tests. Therefore, we expect only minor issues with adoption of 2.0. Those are famous last word, you know. ;) It's better to have a solid contingency plan and never use it than not have it and be forced to scramble in the unlikely case something goes wrong because you "expected only minor issues". Regards, Dominik Yes, we are on the same page here. Michal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Weak deps in updates
Still not working. The only file from updates-testing repo metadata¹ providing "recommends" XML tags is the 2b1dda391308bf7395f9890774b4d2d0692b615c2ad6a73fa378080d32c0c531-primary.xml file, but it just has those tags for 6 packages. ¹ /var/cache/dnf/updates-testing-648243a4cddd356c -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Weak deps in updates
On Thu, Sep 8, 2016 at 5:56 PM, Christian Stadelmann wrote: > Still not working. > > The only file from updates-testing repo metadata¹ providing "recommends" XML > tags is the > 2b1dda391308bf7395f9890774b4d2d0692b615c2ad6a73fa378080d32c0c531-primary.xml > file, but it just has those tags for 6 packages. I don't know why recommends tag for fedora-easy-karma is not appearing in metadata but I can see recommends tag in the same metadata file for the recently built packages like openqa. I think fedora-easy-karma should be the only oldest built package in the f24 updates-testing repository. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Weak deps in updates
So all packages have to be rebuilt to make their weak dependencies go into repo metadata? This was not obvious from the first posting by Kevin Fenzi and probably should go into a separate post here and on devel-announce too. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Weak deps in updates
On Thu, Sep 8, 2016 at 7:21 PM, Christian Stadelmann wrote: > So all packages have to be rebuilt to make their weak dependencies go into > repo metadata? This was not obvious from the first posting by Kevin Fenzi > and probably should go into a separate post here and on devel-announce too. I only provided my observation, I don't have access to bodhi server to look whats happening there exactly. Wait for Kevin's reply on this issue. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 25-20160908.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Failed openQA tests: 11/89 (x86_64), 1/17 (i386), 1/2 (arm) New failures (same test did not fail in 25-20160907.n.0): ID: 32805 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/32805 ID: 32821 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/32821 Old failures (same test failed in 25-20160907.n.0): ID: 32752 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/32752 ID: 32761 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/32761 ID: 32774 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/32774 ID: 32777 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/32777 ID: 32804 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/32804 ID: 32822 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/32822 ID: 32823 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/32823 ID: 32824 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/32824 ID: 32825 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/32825 ID: 32826 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/32826 ID: 32844 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/32844 Passed openQA tests: 78/89 (x86_64), 16/17 (i386) New passes (same test did not pass in 25-20160907.n.0): ID: 32747 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/32747 ID: 32751 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/32751 ID: 32756 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/32756 ID: 32793 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/32793 ID: 32798 Test: x86_64 universal install_delete_partial URL: https://openqa.fedoraproject.org/tests/32798 ID: 32802 Test: x86_64 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/32802 ID: 32839 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/32839 ID: 32843 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/32843 Skipped openQA tests: 1 of 108 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Weak deps in updates
On Thu, 08 Sep 2016 12:26:36 - "Christian Stadelmann" wrote: > Still not working. > > The only file from updates-testing repo metadata¹ providing > "recommends" XML tags is the > 2b1dda391308bf7395f9890774b4d2d0692b615c2ad6a73fa378080d32c0c531-primary.xml > file, but it just has those tags for 6 packages. > > ¹ /var/cache/dnf/updates-testing-648243a4cddd356c Right. It's not working because there were no updates pushes yesterday. We ran into an issue with the f24-updates-testing push and rpm-ostree. The person on push duty spent all day working with ostree folks on a solution. Hopefully we will work around that and/or get the other pushes going today. On Thu, 08 Sep 2016 13:51:20 - "Christian Stadelmann" wrote: > So all packages have to be rebuilt to make their weak dependencies go > into repo metadata? This was not obvious from the first posting by > Kevin Fenzi and probably should go into a separate post here and on > devel-announce too. No. This doesn't need any packages rebuilt. bodhi keeps a cache of repodata, when new updates are added it uses this to allow createrepo to make the repodata faster. Basically it says "Hey, I have all the repodata for the existing updates, you only need to add these new ones". But we need it to regenerate that old repodata, because it was generated with rhel7 rpm and has no weak deps in it. This consists of us removing that repocache directory and doing a push so bodhi tells createrepo "please generate all the repodata for all the packages in this repo". There's nothing maintainers need to do here except wait for the next updates pushes to finish and sync out. Does that make sense? kevin pgpranNEmOU6T.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Schedule for Friday's FESCo Meeting (2016-09-09)
Following is the list of topics that will be discussed in the FESCo meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2016-09-09 16:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1609 Fedora 26 schedule proposal .fesco 1609 https://fedorahosted.org/fesco/ticket/1609 #topic #1617 Council update on Third Party Software policy .fesco 1617 https://fedorahosted.org/fesco/ticket/1617 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/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. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Shared file storage for a Fedora-related project
On Wednesday, September 7, 2016 9:07:12 PM CDT Richard W.M. Jones wrote: > Do we (Fedora) offer any shared file storage for a Fedora-related > project? It's got to store a couple of gigabytes, and allow uploads > from FAS-authenticated users, perhaps using ssh/scp. > > This is for storing the RISC-V RPMs. > > (Apparently fedorahosted is .. dead?) > > Rich. New arch bringup you are supposed to provide your own storage. along with the hardware and infra to run the arches koji instance. Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Shared file storage for a Fedora-related project
On Wed, 07 Sep 2016 15:38:11 -0700 Adam Williamson wrote: > On Wed, 2016-09-07 at 21:48 +0100, Richard W.M. Jones wrote: > > On Wed, Sep 07, 2016 at 01:40:19PM -0700, Adam Williamson wrote: > > > > > On Wed, 2016-09-07 at 21:07 +0100, Richard W.M. Jones wrote: > > > > > > > Do we (Fedora) offer any shared file storage for a > > > > Fedora-related project? It's got to store a couple of > > > > gigabytes, and allow uploads from FAS-authenticated users, > > > > perhaps using ssh/scp. > > > > > > > > This is for storing the RISC-V RPMs. > > > > > > > > (Apparently fedorahosted is .. dead?) > > > > > > fedorapeople's groups space, maybe? > > > > > > https://fedorapeople.org/groups/ > > > > > > we use the qa space there for hosting a few misc. things like > > > kickstarts referred to by test cases. I believe you can request > > > the space you need from the sysadmins and they'll listen to your > > > case. > > > > That sounds interesting. There's a page about this too: > > > > https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org > > > > but I don't see anything about asking for groups to be created. > > I don't think I set up the qa group, so I don't think I've actually > done it. But if I was, I'd probably start by dropping into #fedora- > admin and asking there. Yes, you can file a ticket and request some project/group space there. In fact the aarch64 bring up did that long ago. However /dev/mapper/GuestVolGroup00-project 342G 328G 15G 96% /project we are going to need to get some other projects to clean up their space or try and find more space for that volume. :( I'll send out a call to get people to clean up things they don't need anymore there and see where we are after that. kevin pgpTNboLlkKZk.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide-20160907.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 6/92 (x86_64) New failures (same test did not fail in Rawhide-20160906.n.0): ID: 32969 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/32969 ID: 32970 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/32970 ID: 33059 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/33059 Old failures (same test failed in Rawhide-20160906.n.0): ID: 33027 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/33027 ID: 33034 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/33034 ID: 33036 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/33036 Passed openQA tests: 77/92 (x86_64), 14/17 (i386) New passes (same test did not pass in Rawhide-20160906.n.0): ID: 32964 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/32964 ID: 32971 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/32971 ID: 32976 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/32976 ID: 32986 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/32986 ID: 32988 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/32988 ID: 32990 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/32990 ID: 32993 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/32993 ID: 32995 Test: x86_64 Server-dvd-iso server_role_deploy_database_server URL: https://openqa.fedoraproject.org/tests/32995 ID: 32996 Test: x86_64 Server-dvd-iso server_database_client URL: https://openqa.fedoraproject.org/tests/32996 ID: 33012 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/33012 ID: 33016 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/33016 ID: 33029 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/33029 ID: 33030 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/33030 ID: 33031 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/33031 ID: 33032 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/33032 ID: 33033 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/33033 ID: 33035 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/33035 ID: 33037 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/33037 ID: 33044 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/33044 ID: 33071 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/33071 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Please clean up unneeded files from fedorapeople.org groups and repos
Greetings. There's a large amount of space used on fedorapeople.org for group projects: Filesystem Size Used Avail Use% Mounted on /dev/mapper/GuestVolGroup00-project 342G 328G 15G 96% /project This includes /project/repos/ (which is https://repos.fedorapeople.org) Please take a few minutes to look at any files you or your group may have there and delete anything you no longer need. You may also want to look at your /home directories on fedorapeople.org and clean up any unneeded files there as well. Thanks. kevin pgptguHBpA6l8.pgp Description: OpenPGP digital signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide-20160908.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 11/92 (x86_64), 1/17 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20160907.n.0): ID: 33083 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/33083 ID: 33086 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/33086 ID: 33088 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/33088 ID: 33095 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/33095 ID: 33104 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/33104 ID: 33105 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/33105 ID: 33144 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/33144 ID: 33156 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/33156 ID: 33159 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/33159 ID: 33160 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/33160 ID: 33181 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/33181 Old failures (same test failed in Rawhide-20160907.n.0): ID: 33139 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/33139 ID: 33171 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/33171 Passed openQA tests: 81/92 (x86_64), 16/17 (i386) New passes (same test did not pass in Rawhide-20160907.n.0): ID: 33081 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/33081 ID: 33082 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/33082 ID: 33138 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/33138 ID: 33140 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/33140 ID: 33146 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/33146 ID: 33148 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/33148 ID: 33150 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/33150 ID: 33157 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/33157 ID: 33158 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/33158 ID: 33161 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/33161 ID: 33179 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/33179 ID: 33182 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/33182 Skipped openQA tests: 1 of 111 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Please clean up unneeded files from fedorapeople.org groups and repos
Kevin, help me please with cleanup: [ignatenkobrain@people02 ~][PROD]$ rm -rf /home/fedora/ignatenkobrain/public_git/* rm: cannot remove ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/20/3a73563e678017862cc45354588d40a967a57d’: Permission denied rm: cannot remove ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/8b/cff8eb33b25bef2d995ce4bc420153f2c1aade’: Permission denied rm: cannot remove ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/a8/3159425e2105565b79d0daeef7e16073d0d32a’: Permission denied rm: cannot remove ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/e5/2ea1c393718f48e74abf0c2062b753cb542f4c’: Permission denied rm: cannot remove ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/ef/56842f0422bf92e453ec47c8f1556bdeb04b77’: Permission denied rm: cannot remove ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/f0/5c6e5deddbcc835948588534b0c2f34248d6f6’: Permission denied On Thu, Sep 8, 2016 at 9:20 PM, Kevin Fenzi wrote: > Greetings. > > There's a large amount of space used on fedorapeople.org for group > projects: > > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/GuestVolGroup00-project 342G 328G 15G 96% /project > > This includes /project/repos/ (which is https://repos.fedorapeople.org) > > Please take a few minutes to look at any files you or your group may > have there and delete anything you no longer need. > > You may also want to look at your /home directories on fedorapeople.org > and clean up any unneeded files there as well. > > Thanks. > > kevin > > ___ > devel-announce mailing list > devel-annou...@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
