Re: CI projects in Copr
Hi, > It's easier on implementation. That's the main reason. I generally > believe that > what's easier on implementation is better. It's maybe easier on the copr side, but not for the copr users ... If you can modify the upstream project (either because you are upstream, or in case upstream is willing to accept patches for copr support) you can just use tito and be done with it. If you can't modify upstream it starts to become difficult ... So, what would be really helpful, especially for CI with the option to build and test every upstream commit, would be support for *two* git repos. One git repo where the spec-file and other build-related stuff lives (distgit like). One git repo where the unmodified upstream source lives. Updates on either repo triggers a build. The build runs "git archive" on the upstream repo to generate the tarball and tweaks the specfile (Source and Release tags probably) before kicking off mock for the actual build. cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
Hello Gerd, On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann wrote: > Hi, > > > It's easier on implementation. That's the main reason. I generally > > believe that > > what's easier on implementation is better. > > It's maybe easier on the copr side, but not for the copr users ... > > If you can modify the upstream project (either because you are > upstream, or in case upstream is willing to accept patches for copr > support) you can just use tito and be done with it. > > If you can't modify upstream it starts to become difficult ... > > So, what would be really helpful, especially for CI with the option to > build and test every upstream commit, would be support for *two* git > repos. One git repo where the spec-file and other build-related stuff > lives (distgit like). One git repo where the unmodified upstream > source lives. Updates on either repo triggers a build. The build runs > "git archive" on the upstream repo to generate the tarball and tweaks > the specfile (Source and Release tags probably) before kicking off mock > for the actual build. > Right, this is cool. The problem is that the upstream repo would need to be configured to provide a public message that something has been changed in it (i.e. new release) so the question is how to do this part. All the rest we could probly do with rpkg and a particular downstream repo setup. For Pagure it would be easy because there are fedmsgs, but GitHub, GitLab not so sure. Maybe we could ask upstream to setup a webhook. Not sure. > > cheers, > Gerd > ___ > 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: CI projects in Copr
2017-09-01 11:20 GMT+02:00 Gerd Hoffmann : > So, what would be really helpful, especially for CI with the option to > build and test every upstream commit, would be support for *two* git > repos. One git repo where the spec-file and other build-related stuff > lives (distgit like). One git repo where the unmodified upstream > source lives. Updates on either repo triggers a build. The build runs > "git archive" on the upstream repo to generate the tarball and tweaks > the specfile (Source and Release tags probably) before kicking off mock > for the actual build. That would indeed be very useful! - Thomas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
Hey Marc, On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) wrote: > Quack, > > On 09/01/2017 01:28 AM, Michal Novotny wrote: > > > But I think an off-line talk might be the best. Depends on you. > > I can understand you don't want this thread to end-up in flames, and yes > sometimes it helps to have a live direct talk, but this also means the > rest of this list is kept out. I think it would be best to improve on > collaborative talks together. Also being asked for rational may seem > boring but is really necessary to understand each-other and is in no way > a provocative behavior, even if Pavel seems to like teasing you :-). > sure it would be good but what I would really like to see is a particular concrete, real-world use-case that will not work. Then it would be quite easy to find a solution. Otherwise it's just a matter of taste. Also the thing is that we first need to actually make some changes in COPR code for this to "fit-in" so we don't even need to argue now. We can wait until we have things ready for it. > > I'm really new in here, I'm only using Copr/mock-scm and besides a few > bugs it really suit my simple needs, so I don't have any good suggestion > myself because I don't have a clear view on the need. Nevertheless I was > following the thread so far so I'd like to be able to continue doing so > if I like. > > So if you persist on having private talks, then at least please post a > sum-up here for the rest of the world. > Well, we can continue discussion e.g. also in PRs if people are interested in this. > > Thanks. > \_o< > > > ___ > 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
Splitting AppStream data into Workstation/Server
Hi, I hope that soon the first Cockpit add-on appears in the Fedora repositories. Cockpit can find such add-ons via their AppStream metainfo data, similar to how GNOME Software finds applications to install for a desktop environment. Thus, we would need to install the appstream-data package also on a Server. This is a good enough first step, I guess, but appstream-data is quite big and mostly useless on a Server. We don't need to know about all the desktop applications and their icons. So, what about creating a dedicated appstream-data-server package that carries only those components that we want to see on a Server? Initially, it would contain only components of type "addon" that extend "cockpit.desktop", and components of type "service". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
On Fri, Sep 1, 2017 at 6:37 AM, Marius Vollmer wrote: > Hi, > > I hope that soon the first Cockpit add-on appears in the Fedora > repositories. Cockpit can find such add-ons via their AppStream > metainfo data, similar to how GNOME Software finds applications to > install for a desktop environment. > > Thus, we would need to install the appstream-data package also on a > Server. > > This is a good enough first step, I guess, but appstream-data is quite > big and mostly useless on a Server. We don't need to know about all the > desktop applications and their icons. > > > So, what about creating a dedicated appstream-data-server package that > carries only those components that we want to see on a Server? > > Initially, it would contain only components of type "addon" that extend > "cockpit.desktop", and components of type "service". Please don't do this. This makes AppStream data handling even more complicated than it already is. It's already kind of second-class in Fedora because it's not properly integrated into our repodata (like it's supposed to be, and how it is in openSUSE, Mageia, and even in COPR). We should be making AppStream data support first-class, not third-class. :( -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Module Stream "Expansion"
On 31 August 2017 at 22:09, Matthew Miller wrote: > On Thu, Aug 31, 2017 at 08:11:56PM +1000, Nick Coghlan wrote: >> > 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.) >> If the definition of active stream (for stream expansion purposes) >> were to exclude SL-alpha (and maybe SL-beta) streams in addition to >> EOL ones, then yes, I think that would handle my/our concerns, as then >> there would be a way to indicate that a *new* streams should be >> considered inactive without needing to set a misleading EOL date. > > I think we'd probably _still_ want it active, because even if it fails, > it's nice to know that sooner rather than later. The case we're concerned about is the one at the start of bootstrapping a new Python feature release where some of the virtual environment management features are missing because the package management tools haven't been built for that stream yet. While the stream is in that state (which is only temporary, but still a non-zero amount of time if we want to avoid relying on binaries built from a previous stream), other build failures are reasonably likely to be due to the bootstrapping being incomplete, which means higher level module builds won't provide useful compatibility information until the bootstrapping is complete and the stream is in a "OK, this is expected to work normally now" state. I believe this problem technically already exists with Rawhide today, but hitting it requires folks to be submitting new Rawhide builds for Python packages precisely while the Rawhide Python stack is in the middle of being rebased. If I correctly understand how it's going to work, the potential ripple effect with the module build system is much worse, as the sequence of events will be: * partial build gets published while bootstrapping a new stream * stream expansion detects a whole lot of higher level modules now missing and submits builds for them * those automatic builds all fail because the new stream wasn't ready for them yet So the request is for there to be a way to indicate that a stream is available for explicit dependencies, but *shouldn't* be taken into account for implicit stream expansion yet. Then, once the low level stream is stable, *then* its maintainers can flick the switch to say "OK, this looks healthy, start building new variants of all the modules that depend on this one". 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: CI projects in Copr
Hi, > Right, this is cool. The problem is that the upstream repo would need > to be configured to provide a public message that something has been > changed > in it (i.e. new release) so the question is how to do this part. Ah, right, setting up a webhook needs access to the upstream repo too. Add support for polling then? Possibly at large intervals only to cap the resources spent on this? Maybe once per day, so one could do nightly builds with this? cheers, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
Neal Gompa writes: >> So, what about creating a dedicated appstream-data-server package that >> carries only those components that we want to see on a Server? >> >> Initially, it would contain only components of type "addon" that extend >> "cockpit.desktop", and components of type "service". > > Please don't do this. What should I be doing instead? Nothing? :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer wrote: > Neal Gompa writes: > >>> So, what about creating a dedicated appstream-data-server package that >>> carries only those components that we want to see on a Server? >>> >>> Initially, it would contain only components of type "addon" that extend >>> "cockpit.desktop", and components of type "service". >> >> Please don't do this. > > What should I be doing instead? Nothing? :-) Implement your AppStream filter at the application level, rather than messing with appstream-data package. That makes it more portable and won't do dumb things. We already ship the appstream-data package in the Workstation Edition and on all the spins, so just add it to the Server Edition if it isn't already there. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
Marius Vollmer wrote: > Neal Gompa writes: > >>> So, what about creating a dedicated appstream-data-server package that >>> carries only those components that we want to see on a Server? >>> >>> Initially, it would contain only components of type "addon" that extend >>> "cockpit.desktop", and components of type "service". >> >> Please don't do this. > > What should I be doing instead? Nothing? :-) Yes, leave appstream-data all in one piece as-is. I'd echo Neal's sentiments in this regard. -- rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
are the armv7hl builders healthy?
I'm trying to build ceph-12.2.0 for f28, So far the build has failed twice on armv7hl during %install trying to install a file that was seeminlyly successfully built. That's two different files. The first time it was cephfs-journal-tool, the second time it was the one immediately after: cephfs-table-tool. The other six archs builds are successful and building 12.1.4 a week ago worked. Am I running into quotas or some other file system space limitation? The most recent build log is at https://kojipkgs.fedoraproject.org//work/tasks/3484/21583484/build.log The previous build log is at https://kojipkgs.fedoraproject.org//work/tasks/7134/21537134/build.log Any thoughts? Thanks -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
On Fri, Sep 1, 2017 at 1:41 PM, Gerd Hoffmann wrote: > Hi, > > > Right, this is cool. The problem is that the upstream repo would need > > to be configured to provide a public message that something has been > > changed > > in it (i.e. new release) so the question is how to do this part. > > Ah, right, setting up a webhook needs access to the upstream repo too. > > Add support for polling then? Possibly at large intervals only to cap > the resources spent on this? Maybe once per day, so one could do > nightly builds with this? > I mean, it would be possible for sure. We will see. > > cheers, > Gerd > ___ > 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: are the armv7hl builders healthy?
On Fri, Sep 01, 2017 at 08:17:11AM -0400, Kaleb Keithley wrote: > > I'm trying to build ceph-12.2.0 for f28, So far the build has failed twice > on armv7hl during %install trying to install a file that was seeminlyly > successfully built. > > That's two different files. The first time it was cephfs-journal-tool, the > second time it was the one immediately after: cephfs-table-tool. > > The other six archs builds are successful and building 12.1.4 a week ago > worked. > > Am I running into quotas or some other file system space limitation? > > The most recent build log is at > https://kojipkgs.fedoraproject.org//work/tasks/3484/21583484/build.log > > The previous build log is at > https://kojipkgs.fedoraproject.org//work/tasks/7134/21537134/build.log > > Any thoughts? Is there any way to fix cmake or the ceph cmake rules so that they report the real useful error message, instead of throwing it away & providing a generic "cannot copy file" message with no details ? Its hard to diagnose without knowing the real error message from the OS Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
On pe, 01 syys 2017, Neal Gompa wrote: On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer wrote: Neal Gompa writes: So, what about creating a dedicated appstream-data-server package that carries only those components that we want to see on a Server? Initially, it would contain only components of type "addon" that extend "cockpit.desktop", and components of type "service". Please don't do this. What should I be doing instead? Nothing? :-) Implement your AppStream filter at the application level, rather than messing with appstream-data package. That makes it more portable and won't do dumb things. We already ship the appstream-data package in the Workstation Edition and on all the spins, so just add it to the Server Edition if it isn't already there. $ rpm -qi appstream-data|egrep '(Name|Version|Release|Size)' Name: appstream-data Version : 26 Release : 14.fc26 Size: 1563 This is what Marius is talking about -- there is little insentive to install 15MiB of data largely unused on Fedora Server if all you'd need is a ~1KiB. Filtering this information on the application side is OK if it would have been not so useless in the Server installs. -- / Alexander Bokovoy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
On Fri, Sep 1, 2017 at 8:37 AM, Alexander Bokovoy wrote: > On pe, 01 syys 2017, Neal Gompa wrote: >> >> On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer >> wrote: >>> >>> Neal Gompa writes: >>> > So, what about creating a dedicated appstream-data-server package that > carries only those components that we want to see on a Server? > > Initially, it would contain only components of type "addon" that extend > "cockpit.desktop", and components of type "service". Please don't do this. >>> >>> >>> What should I be doing instead? Nothing? :-) >> >> >> Implement your AppStream filter at the application level, rather than >> messing with appstream-data package. That makes it more portable and >> won't do dumb things. We already ship the appstream-data package in >> the Workstation Edition and on all the spins, so just add it to the >> Server Edition if it isn't already there. > > $ rpm -qi appstream-data|egrep '(Name|Version|Release|Size)' > Name: appstream-data > Version : 26 > Release : 14.fc26 > Size: 1563 > > This is what Marius is talking about -- there is little insentive to > install 15MiB of data largely unused on Fedora Server if all you'd need > is a ~1KiB. > > Filtering this information on the application side is OK if it would > have been not so useless in the Server installs. If you're only using 1 KiB of it due to not having much in there, then perhaps you need to make more things available via AppStream information. That said, 15MB is *nothing*. The only reason it might be a problem is because PackageKit still cannot do DeltaRPMs (so it's a bit of a bandwidth hog). But that should be fixable. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 8:37 AM, Alexander Bokovoy wrote:
On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
wrote:
Neal Gompa writes:
So, what about creating a dedicated appstream-data-server package that
carries only those components that we want to see on a Server?
Initially, it would contain only components of type "addon" that extend
"cockpit.desktop", and components of type "service".
Please don't do this.
What should I be doing instead? Nothing? :-)
Implement your AppStream filter at the application level, rather than
messing with appstream-data package. That makes it more portable and
won't do dumb things. We already ship the appstream-data package in
the Workstation Edition and on all the spins, so just add it to the
Server Edition if it isn't already there.
$ rpm -qi appstream-data|egrep '(Name|Version|Release|Size)'
Name: appstream-data
Version : 26
Release : 14.fc26
Size: 1563
This is what Marius is talking about -- there is little insentive to
install 15MiB of data largely unused on Fedora Server if all you'd need
is a ~1KiB.
Filtering this information on the application side is OK if it would
have been not so useless in the Server installs.
If you're only using 1 KiB of it due to not having much in there, then
perhaps you need to make more things available via AppStream
information.
We plan to start using AppStream to advertise Cockpit-integrated
plugins. Currently there is one in Fedora and another one is coming.
This is not about not having AppStream information for already existing
applications but rather not having those applications at all (yet).
Even when they will be created and AppStream information would be added
for them, most if not all Workstation-oriented content of AppStream will
have no use in the Server context.
That said, 15MB is *nothing*. The only reason it might be a problem is
because PackageKit still cannot do DeltaRPMs (so it's a bit of a
bandwidth hog). But that should be fixable.
Forcing every cockpit deployment to bring another 15MB while the whole
cockpit install is 3MB is definitely too much.
$ rpm -qa| grep cockpit|xargs -n1 rpm -qi|grep Size|cut -d: -f2|awk '{s+=$1} END {print s}'
3113811
--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
On Fri, Sep 1, 2017 at 8:57 AM, Alexander Bokovoy wrote:
> On pe, 01 syys 2017, Neal Gompa wrote:
>>
>> On Fri, Sep 1, 2017 at 8:37 AM, Alexander Bokovoy
>> wrote:
>>>
>>> On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
wrote:
>
>
> Neal Gompa writes:
>
>>> So, what about creating a dedicated appstream-data-server package
>>> that
>>> carries only those components that we want to see on a Server?
>>>
>>> Initially, it would contain only components of type "addon" that
>>> extend
>>> "cockpit.desktop", and components of type "service".
>>
>>
>>
>> Please don't do this.
>
>
>
> What should I be doing instead? Nothing? :-)
Implement your AppStream filter at the application level, rather than
messing with appstream-data package. That makes it more portable and
won't do dumb things. We already ship the appstream-data package in
the Workstation Edition and on all the spins, so just add it to the
Server Edition if it isn't already there.
>>>
>>>
>>> $ rpm -qi appstream-data|egrep '(Name|Version|Release|Size)'
>>> Name: appstream-data
>>> Version : 26
>>> Release : 14.fc26
>>> Size: 1563
>>>
>>> This is what Marius is talking about -- there is little insentive to
>>> install 15MiB of data largely unused on Fedora Server if all you'd need
>>> is a ~1KiB.
>>>
>>> Filtering this information on the application side is OK if it would
>>> have been not so useless in the Server installs.
>>
>>
>> If you're only using 1 KiB of it due to not having much in there, then
>> perhaps you need to make more things available via AppStream
>> information.
>
> We plan to start using AppStream to advertise Cockpit-integrated
> plugins. Currently there is one in Fedora and another one is coming.
> This is not about not having AppStream information for already existing
> applications but rather not having those applications at all (yet).
>
> Even when they will be created and AppStream information would be added
> for them, most if not all Workstation-oriented content of AppStream will
> have no use in the Server context.
>
>> That said, 15MB is *nothing*. The only reason it might be a problem is
>> because PackageKit still cannot do DeltaRPMs (so it's a bit of a
>> bandwidth hog). But that should be fixable.
>
> Forcing every cockpit deployment to bring another 15MB while the whole
> cockpit install is 3MB is definitely too much.
>
> $ rpm -qa| grep cockpit|xargs -n1 rpm -qi|grep Size|cut -d: -f2|awk '{s+=$1}
> END {print s}' 3113811
Think about more than Server for a second here. Cockpit is a perfectly
nice way to manage your own workstation too. I use it myself on my
machines because it provides an awesome interface for a lot of stuff.
It's not just about your vision of usage, it's about how everyone else
uses it too! :)
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
Neal Gompa writes: > Implement your AppStream filter at the application level, rather than > messing with appstream-data package. Yes, of course. Cockpit will do the right thing even with the full appstream-data package. This is only about not having 15 MiB of useless data installed. I have no strong opinion either way. Not splitting the package is of course the easiest and cleanest thing to do. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
On Fri, Sep 1, 2017 at 9:03 AM, Richard Hughes wrote: > On Fri, Sep 1, 2017 at 2:00 PM, Neal Gompa wrote: >> It's not just about your vision of usage, it's about how everyone else >> uses it too! :) > > Well, we could do the opposite, we could just include cockpit data in > appstream-data and then put the desktop-specific stuff in a > appstream-data-desktop subpackage and require the latter by > gnome-software. > > Richard. I'm well aware, and I didn't want to bring that up because the point was that we shouldn't do *any* splitting of the AS data, as it's representative of the Fedora system as a whole. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
AppStream and COPR (was: Splitting AppStream data into Workstation/Server)
Neal Gompa writes: > [...] It's already kind of second-class in Fedora because it's not > properly integrated into our repodata (like it's supposed to be, and > how it is in openSUSE, Mageia, and even in COPR). > > We should be making AppStream data support first-class, not > third-class. :( This is interesting. Can you point me to more information about AppStream and COPR? I have a COPR with some AppStream metainfo files in it, and I noticed that suddenly I had this file: /var/cache/app-info/xmls/mvo-cockpit-app-freeipa.xml.gz I have since deleted it and it doesn't seem to come back. If memory serves, I think it was referenced from repodata/repomd.xml back then, but not anymore. Anyway, now there is appdata/appstream.xml.gz in the repo: https://copr-be.cloud.fedoraproject.org/results/mvo/cockpit-app-freeipa/fedora-26-x86_64/appdata/ Is dnf supposed to download this automatically? Some other program? Should the consumer (such as GNOME Software and Cockpit) download it explicitly? Also, addons don't work in COPRs: https://pagure.io/copr/copr/issue/128 Also also, what will you do with icons? Do they all have to be type="remote"? Will you automatically convert type="local" icons to type="remote" icons? Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-01 at 16:01 +0300, Marius Vollmer wrote: > Neal Gompa writes: > > > Implement your AppStream filter at the application level, rather > > than > > messing with appstream-data package. > > Yes, of course. Cockpit will do the right thing even with the full > appstream-data package. This is only about not having 15 MiB of > useless > data installed. Just check how much data you download for repository metadata.. 😉 > > I have no strong opinion either way. Not splitting the package is of > course the easiest and cleanest thing to do. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpXmYACgkQaVcUvRu8 X0zSDA//Si4mA9/0aGRxrM+iHPVEFEjWiIXR8ImGNkBf6oovKR2ED+RZj95HfVxZ EVBZ5qTHe71SW3cjaq0o2RXsoBNN6uhrZ54R5b+MwaYG4Ong2JmvqDW98EbT/Vx0 tiIbW9TMi/7D+s087gthTj2QTsj5CoNM8dwOAaAIW8o8va0kLZXFQg+7A2WmToq5 oFj3yXQJoPYtDkUJ50OK4cvgW71Zpe5TT1Z4aOZggWsZZNJ8+4cU9FicNS9kHAq+ 2bpEnEOyPaKMF8UMKtysXqknDIoAigtwkatpcFNx9VNA0R7z6kIvIyThotxbogyI CHwEFapg+M0YiP7/pFNyNF/uxYqoS3sXlK40g9C4Lw0d8DSpJWiAPUyQSDVSoq2n mKtEcQ+tKwpVssnv+B4sDdGEfsH/IrcFIz5NyIEgzO/kdMdq9R0Vko3Vce2BLPQT Qkjbe+uXuYGTd/nuCuLG63AXVVrK704d1KssP5qZGSY/MyF41eGIihRbkM/tP3gV yD5hbkWM0/PTc8XVqBZcIZuWh+yIqfsUw9qgWkUa/0ABZ+u46f0ubU/5MSHsxq/X HKUg7aaI9g4sWduk5bC4Yl6pYiJKfWMcB61VoJAEfnAPV4RrJq4me6w6cyzDMoGs YZ8cFm+eJ9a0lYaxpn6DkUZuj1v6MW2RYhIkTYOgTb4ox/0QplU= =fmJm -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: are the armv7hl builders healthy?
Is there any way to fix cmake or the ceph cmake rules so that they report
the real useful error message, instead of throwing it away & providing a
generic "cannot copy file" message with no details ?
Quick and dirty: prefix all commands with something like
strace -o "| grep '= -1'"
Example:
$ strace -o "| grep '= -1'" /bin/true
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
$
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: AppStream and COPR (was: Splitting AppStream data into Workstation/Server)
On Fri, Sep 1, 2017 at 9:12 AM, Marius Vollmer wrote: > Neal Gompa writes: > >> [...] It's already kind of second-class in Fedora because it's not >> properly integrated into our repodata (like it's supposed to be, and >> how it is in openSUSE, Mageia, and even in COPR). >> >> We should be making AppStream data support first-class, not >> third-class. :( > > This is interesting. Can you point me to more information about > AppStream and COPR? > There's no real documentation on this, as far as I know, but the COPR developers know more about it (they're CC'd to this email). > > I have a COPR with some AppStream metainfo files in it, and I noticed > that suddenly I had this file: > > /var/cache/app-info/xmls/mvo-cockpit-app-freeipa.xml.gz > > I have since deleted it and it doesn't seem to come back. If memory > serves, I think it was referenced from repodata/repomd.xml back then, > but not anymore. > > Anyway, now there is appdata/appstream.xml.gz in the repo: > > > https://copr-be.cloud.fedoraproject.org/results/mvo/cockpit-app-freeipa/fedora-26-x86_64/appdata/ > > Is dnf supposed to download this automatically? Some other program? > Should the consumer (such as GNOME Software and Cockpit) download it > explicitly? > All PackageKit based software managers automatically download the data, as the Dnf PK backend does this: https://github.com/hughsie/PackageKit/blob/master/backends/dnf/pk-backend-dnf.c#L553 DNF currently ignores it, though it can be made to handle it. As an aside, libzypp/Zypper (F26+) does download and handle AppStream data, when available. > Also, addons don't work in COPRs: https://pagure.io/copr/copr/issue/128 > > Also also, what will you do with icons? Do they all have to be > type="remote"? Will you automatically convert type="local" icons to > type="remote" icons? > COPR runs createrepo_c, then appstream-builder, then modifyrepo_c to create the rpm-md repodata, generate the appstream repodata, and append the appstream repodata to the rpm-md repodata. You can see the appstream bundle in the repodata folder: https://copr-be.cloud.fedoraproject.org/results/mvo/cockpit-app-freeipa/fedora-26-x86_64/repodata/669caf74c17cec488cc84ee5eadf4f4f02c7b34a84fd4664b4148c1422e4186d-appstream.xml.gz And it's referenced in the repomd.xml file: https://copr-be.cloud.fedoraproject.org/results/mvo/cockpit-app-freeipa/fedora-26-x86_64/repodata/repomd.xml Behaviors related for icon type is appstream-builder handling. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: AppStream and COPR (was: Splitting AppStream data into Workstation/Server)
Neal Gompa writes: > All PackageKit based software managers automatically download the > data, as the Dnf PK backend does this: > https://github.com/hughsie/PackageKit/blob/master/backends/dnf/pk-backend-dnf.c#L553 Ahh, thanks! "pkcon refresh force" indeed downloads it for me. > You can see the appstream bundle in the repodata folder: > https://copr-be.cloud.fedoraproject.org/results/mvo/cockpit-app-freeipa/fedora-26-x86_64/repodata/669caf74c17cec488cc84ee5eadf4f4f02c7b34a84fd4664b4148c1422e4186d-appstream.xml.gz > > And it's referenced in the repomd.xml file: > https://copr-be.cloud.fedoraproject.org/results/mvo/cockpit-app-freeipa/fedora-26-x86_64/repodata/repomd.xml Great, thanks for showing me this. I must have confused myself somehow. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: AppStream and COPR
Dne 1.9.2017 v 15:31 Neal Gompa napsal(a):
> On Fri, Sep 1, 2017 at 9:12 AM, Marius Vollmer
> wrote:
>> Neal Gompa writes:
>>
>>> [...] It's already kind of second-class in Fedora because it's not
>>> properly integrated into our repodata (like it's supposed to be, and
>>> how it is in openSUSE, Mageia, and even in COPR).
>>>
>>> We should be making AppStream data support first-class, not
>>> third-class. :(
>>
>> This is interesting. Can you point me to more information about
>> AppStream and COPR?
There is no documentation. It is as simple as "Copr fully support AppStream". :)
> COPR runs createrepo_c, then appstream-builder, then modifyrepo_c to
> create the rpm-md repodata, generate the appstream repodata, and
> append the appstream repodata to the rpm-md repodata.
>
> You can see the appstream bundle in the repodata folder:
> https://copr-be.cloud.fedoraproject.org/results/mvo/cockpit-app-freeipa/fedora-26-x86_64/repodata/669caf74c17cec488cc84ee5eadf4f4f02c7b34a84fd4664b4148c1422e4186d-appstream.xml.gz
>
> And it's referenced in the repomd.xml file:
> https://copr-be.cloud.fedoraproject.org/results/mvo/cockpit-app-freeipa/fedora-26-x86_64/repodata/repomd.xml
*nod* Technically speaking we run:
APPDATA_CMD_TEMPLATE = \
"""/usr/bin/timeout --kill-after=240 180 \
/usr/bin/appstream-builder \
--max-threads=4 \
--temp-dir={packages_dir}/tmp \
--cache-dir={packages_dir}/cache \
--packages-dir={packages_dir} \
--output-dir={packages_dir}/appdata \
--basename=appstream \
--include-failed \
--min-icon-size=48 \
--enable-hidpi \
--origin={username}/{projectname}
"""
INCLUDE_APPSTREAM = \
"""/usr/bin/modifyrepo_c \
--no-compress \
{packages_dir}/appdata/appstream.xml.gz \
{packages_dir}/repodata
"""
INCLUDE_ICONS = \
"""/usr/bin/modifyrepo_c \
--no-compress \
{packages_dir}/appdata/appstream-icons.tar.gz \
{packages_dir}/repodata
"""
Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Module Stream "Expansion"
On Fri, Sep 01, 2017 at 09:25:22PM +1000, Nick Coghlan wrote: > So the request is for there to be a way to indicate that a stream is > available for explicit dependencies, but *shouldn't* be taken into > account for implicit stream expansion yet. Then, once the low level > stream is stable, *then* its maintainers can flick the switch to say > "OK, this looks healthy, start building new variants of all the > modules that depend on this one". Okay, I get it now. :) I still think the Service Level field would be useful here; maybe by policy dependent modules wouldn't be auto-expanded against streams tagged as "alpha". -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Providing ABI/API assurances for the base runtime in Fedora.
Fedora Developers, I am working on a way to provide concrete ABI/API assurances for parts of the base runtime. I've written up some of the key ideas here: https://fedoraproject.org/wiki/BaseRuntimeInterface Any feedback would be appreciated, including bikeshed on component name prefix for frozen interface pakcages e.g. base-*. -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Providing ABI/API assurances for the base runtime in Fedora.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-01 at 09:28 -0500, Carlos O'Donell wrote: > Fedora Developers, > > I am working on a way to provide concrete ABI/API assurances for > parts of the base runtime. Note that Base Runtime is F26-only thing and in F27 it is called Host and Platform[0].. > > I've written up some of the key ideas here: > https://fedoraproject.org/wiki/BaseRuntimeInterface > > Any feedback would be appreciated, including bikeshed on component > name prefix for frozen interface pakcages e.g. base-*. Why do we need separate components? Can't we adjust main packages to install into separate paths? In theory, it should be just setting differeng %_prefix variable for RPM. Another thing to mention is that libabigail currently (as far as I know) doesn't handle python code/python extensions (read DNF). Also I guess it doesn't handle GObject Introspected code. > > -- > Cheers, > Carlos. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org [0]https://fedoraproject.org/wiki/Changes/Host_and_Platform - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpdhIACgkQaVcUvRu8 X0wBoBAApfw/InR9lDuN1uQ3vdU2FlShLUfbUt21PweLrfXHIl4rM6IOh4TpTkce E/A0Uyc4cMdJdROrP3T9yZhaH5D9wo5z0gimM1hF/KeOFRC3yg8iSmhCgeAw4QxV F1wFYjBcinq8bb282BgF6rRLusWSGh03gWn80NImBByZA0F1eYHpPsvBCwOMG6Vg ZfHa0g+mZb8yP5bElgUSyRpSqFGFlp6aRdTwpIafIXUJ+hy2rsrxjPDn95O66TOf OJKSpMR20lCqeWdLPGuGXuJvYbAMkYuKZbQZAowzs+Q4Sc8RYKFty6bYGFNcpMSC oN65nDDNFqWZzhA9UuFWPgCBvbG91WarfwiAix8w2PXygklbSbcFNmjOaedJc3gH RJ83n8i3Yi6+AS0Ru0ZfZ58afq+88jtypy4dW6qRGKgfaHckf61/4cxa8iXS03nY kILkdSmrM7Abcy9Z51cAA5h5jM54+IiYsqZfPhIDeBxrAIaR++K8llVP/6azMIwf fw47Va8t0DkXNgpt4NsKk68Vgx6yAp9W0W449e9xVz5ZDCjOkZtTvsfQABByfPfk cm2ByUhgrfRyp0N/R7MYX2e+C3fC2lbdJmbSTQ5Xmno0RktrWu50GRW2h+CV3AUp Xs2wTyJbn8Aq18wha6/dk3n7EtY7IS+DuYGB1fFibTnKzHAw9p4= =6/Bf -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Schedule for today's FESCo Meeting (2017-09-01)
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 '2017-09-01 16:00 UTC' Links to all issues below can be found at: https://pagure.io/fesco/report/meeting_agenda = Followups = #topic #1761 Update of "Fedora Release Live Cycle" and "Changes / Policy" .fesco 1761 https://pagure.io/fesco/issue/1761 #topic #1763 Fedora Modules Guidelines and Process .fesco 1763 https://pagure.io/fesco/issue/1763 #topic #1765 Proposed Fedora 28 schedule .fesco 1765 https://pagure.io/fesco/issue/1765 = New business = #topic #1767 F28 Self Contained Changes .fesco 1767 https://pagure.io/fesco/issue/1767 #topic #1768 fesco input for Outreachy projects .fesco 1768 https://pagure.io/fesco/issue/1768 Topic #1769 F28 System Wide Change: Switch libidn-using applications to IDNA2008 .fesco 1769 https://pagure.io/fesco/issue/1769 = 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. ___ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Schedule for today's FESCo Meeting (2017-09-01)
Also new business: #topic #1766 Is ImageMagick 7 appropriate for Fedora 27 (and even 28)? .fesco 1766 https://pagure.io/fesco/issue/1766 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: FAILED: BuildError: package ... not in list for tag f28-pending
On Thu, 31 Aug 2017 22:14:11 +0200, Björn 'besser82' Esser wrote: > > It's been several hours since this entirely new package repo has been > > created, > > but the koji build still fails. How long does it take for koji to learn > > about this new package? > it takes as long someone from releng tells Koji manually about it… It > can take up to one day. What a surprise! Why is it a separate procedure from the repository creation step? Could a status update be added to the ticket that one opens? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: FAILED: BuildError: package ... not in list for tag f28-pending
On 01/09/17 17:26, Michael Schwendt wrote: On Thu, 31 Aug 2017 22:14:11 +0200, Björn 'besser82' Esser wrote: It's been several hours since this entirely new package repo has been created, but the koji build still fails. How long does it take for koji to learn about this new package? it takes as long someone from releng tells Koji manually about it… It can take up to one day. What a surprise! Why is it a separate procedure from the repository creation step? Could a status update be added to the ticket that one opens? Well as I understand it the idea is that it should happen automatically but there is a bug that has yet to be tracked down and hence it is currently being done manually when the automatic update fails. 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
RFC: retiring yum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 So I think F28/F29 would be best time for retiring YUM. Right now DNF should be already stable and provide same capabilities (or documented that something will not be supported). Hopefully infrastructure / rel-eng folks will finally add support for rich dependencies[0] which would mean that yum will not work in Fedora anyway, so.. Do you still have some critical missing functionality in DNF? And let us know reasons why would you like to keep YUM available (hopefully there are no)! P.S. I didn't wrote any Change Proposal yet, want to get feedback first [0] https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_ and_libraries - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpkn0ACgkQaVcUvRu8 X0y2zA/+O5rG2QGHdoZOsQhE5H8Q5MRpdO3jQxgqC9+atQtV0MWNkmkxyPCbY2no smHeOaW8OjqvjhN+JuzaWDpjZY/aFmnVijnpCBLtx5sNKNLuz4VPN66ZK6wVLT5j Nst0BiUglXJxIj32NswyQ+jNl7iFuFUWUrVlUNFYP3YiURvCRd/B/l2XHWDtkH0M GUWTARf5a0LSXPxpbwQ/g+jkstbie3CIQe5nlw7oiCJgYPwoY2VuIvo1l/Uvn2My 6Ip3NiZwlihJ3x5iM3bisdCYW7+c0/rMV6IFGV4J94/3Rl1U3kzGsI5SVW/An2mf s3xNP2EutZsccFrudromFvYE6BeWwMr2BVb+fMzt9S9zEIKZvx9IMQgZMgqR7IPH 3t6P1R5WD3o0q4I+vOc0IPtyqHnqKAVE/6tMr9mqQP4PBswa1uyhLeravDAGTHYC XvyU6Y3ONmZA1I75Pb2tbVNBlpPB2QZGGf46ayTi2i0Jb6/ctoda5Lbpc/2iD3Be /e/f3yxHQHgQFSkwAkz2K4INuSf7lpIB3uQEnVhJRk8+75nvKvxNRwW5vEMOs50Q DVjKI8BRW02K4BjU7FnBNjezv/2A/ygIU4swQ3/0E/CKQ0LG2CWY2sgAqEutEpz2 kmarL+xaZAD1QA7ohqMbQeMFkIdK1hy2JAkxWdYUgWHBeRr7rIo= =ImZb -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2017-09-01)
https://meetbot.fedoraproject.org/fedora-meeting/2017-09-01/fesco.2017-09-01-16.02.log.html . Meeting summary --- * init process (jforbes, 16:02:16) * #1761 Update of "Fedora Release Live Cycle" and "Changes / Policy" (jforbes, 16:06:01) * LINK: https://pagure.io/fesco/issue/1761 (jforbes, 16:06:02) * maxamillion forgot to update tickets from last week, meeting minutes here: https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-08-25-16.00.html issues will be updated (maxamillion, 16:06:40) * AGREED: Update of "Fedora Release Live Cycle" and "Changes / Policy" is approved (+8,0,-0) (jforbes, 16:16:58) * #1765 Proposed Fedora 28 schedule (jforbes, 16:17:13) * LINK: https://pagure.io/fesco/issue/1765 (jforbes, 16:17:13) * LINK: https://pagure.io/fesco/issue/1767 (jforbes, 16:19:01) * #1767 F28 Self Contained Changes (jforbes, 16:27:34) * AGREED: defrer until either a) we know the toolchain is ready (ie, bodhi is using pungi) or b) after jan 30th (+8,0,-0) (jforbes, 16:40:22) * #1768 fesco input for Outreachy projects (jforbes, 16:40:38) * LINK: https://pagure.io/fesco/issue/1768 (jforbes, 16:40:39) * AGREED: FESCo will give input for Outreachy projects (+8,0,-0) (jforbes, 16:44:12) * jsmith or sgallagh allah will represent FESCo (tyll, 16:44:47) * #1769 F28 System Wide Change: Switch libidn-using applications to IDNA2008 (jforbes, 16:44:53) * LINK: https://pagure.io/fesco/issue/1769 (jforbes, 16:44:54) * AGREED: F28 System Wide Change: Switch libidn-using applications to IDNA2008 is approved (+8,0,-0) (jforbes, 16:47:18) * #1766 Is ImageMagick 7 appropriate for Fedora 27 (and even 28)? (jforbes, 16:47:30) * LINK: https://pagure.io/fesco/issue/1766 (jforbes, 16:47:31) * proposal is to make imagemagick 7 a system wide change for F28 and not have anything on default install or blocking F27 media require imagemagick 7 (tyll, 16:50:59) * AGREED: sgallagh's proposal in ticket is accepted (+8,0,-0) (jforbes, 16:52:56) * Next Week's chair (jforbes, 16:53:11) * nirik will chair next weeks meeting (jforbes, 16:55:20) * open floor (jforbes, 16:55:36) * next weeks meeting will be at the same time as current since we do not have whenisgood results (jforbes, 16:56:23) Meeting ended at 17:11:11 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * jforbes (55) * maxamillion (44) * nirik (38) * bowlofeggs (33) * dgilmore (25) * zodbot (24) * ignatenkobrain (23) * adamw (22) * jsmith (20) * kalev (18) * mattdm (16) * tyll (14) * puiterwijk (5) * langdon (5) * sgallagh (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > So I think F28/F29 would be best time for retiring YUM. Right now DNF > should be already stable and provide same capabilities (or documented > that something will not be supported). > > Hopefully infrastructure / rel-eng folks will finally add support for > rich dependencies[0] which would mean that yum will not work in Fedora > anyway, so.. > > Do you still have some critical missing functionality in DNF? And let > us know reasons why would you like to keep YUM available (hopefully > there are no)! > There is still one thing I've noticed we're missing: API and CLI for getting package changelogs[1]. This exists in yum but doesn't in dnf. In addition, don't we still need yum in the repositories for mock to target EL6 and EL7 for EPEL? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1066867 (CLI RFEs are blocked by this bug) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On Mon, 2017-08-28 at 20:39 -0500, Michael Cronenworth wrote: > Rebuild status: > * All F25/F26 packages have been rebuilt against ImageMagick 6.9.9.9 > * Most of the F27+ packages have been rebuilt with the following exceptions: > - cuneiform > FTBFS since Fedora 23, last upstream release is from 2011 > - imageinfo > Requires porting, upstream is alive. I may come back and fix this later. > CC'ing maintainer. > - perl-Image-SubImageFind > Requires porting, upstream is dead > - psiconv > Requires porting, upstream is dead > - q > Obsolete back in 2008, replaced by "Pure" language... which is not in > Fedora > - rubygem-rmagick > Requires porting, upstream is alive, but not interested. I'll have to > come back to this one. CC'ing maintainer. > > The rebuilt packages are using a direct support style patch and not a > comprehensive support patch. I'll be making comprehensive patches when I have > time and shipping them upstream. If anyone wants to create a patch before I > do please feel free. Just link the upstream git commit or report with the > patch. Thanks Michael! FESCo decided at today's meeting that 7 should not go to F27 (unless it can be made parallel installable and not used by anything release- blocking by default), and to go into F28 there must be a system-wide Change: https://pagure.io/fesco/issue/1766 I'm happy to do the downgrade + rebuilds for F27 (when I'm back from Flock), we'll have to decide precisely what to do with Rawhide. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On 09/01/2017 12:01 PM, Igor Gnatenko wrote: Do you still have some critical missing functionality in DNF? And let us know reasons why would you like to keep YUM available (hopefully there are no)! AFAIK there is still no way to get dependency information out of DNF. (There may be a way to do it, but --verbose certainly doesn't.) -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On 2017-09-01 1:01 PM, Igor Gnatenko wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 So I think F28/F29 would be best time for retiring YUM. Right now DNF should be already stable and provide same capabilities (or documented that something will not be supported). Hopefully infrastructure / rel-eng folks will finally add support for rich dependencies[0] which would mean that yum will not work in Fedora anyway, so.. Do you still have some critical missing functionality in DNF? And let us know reasons why would you like to keep YUM available (hopefully there are no)! I should have paid more attention to this, but I still traumatized and avoid looking at anything related to yum. 1) Can we use existing repositories created with yum createrepo with dnf? 2) Are "groups" supported? (E.g.: yum instalgroup xxx) Thanks, Fernando P.S. I didn't wrote any Change Proposal yet, want to get feedback first [0] https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_ and_libraries - -- - -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On Fri, Sep 01, 2017 at 02:38:59PM -0400, Fernando Nasser wrote: > 1) Can we use existing repositories created with yum createrepo with dnf? Yes. > 2) Are "groups" supported? (E.g.: yum instalgroup xxx) Yes. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On 2017-09-01 2:52 PM, Matthew Miller wrote: On Fri, Sep 01, 2017 at 02:38:59PM -0400, Fernando Nasser wrote: 1) Can we use existing repositories created with yum createrepo with dnf? Yes. 2) Are "groups" supported? (E.g.: yum instalgroup xxx) Yes. Thanks Matthew. I guess it will be just access to information via cli and api as people have brought up. Cheers, Fernando ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Raising requirement for application icons in GNOME Software
Hi all, At the moment the appstream-builder requires a 48x48px application icon[1] to be included in the AppStream metadata. I'm sure it's no surprise that 48x48 padded to 64x64 and then interpolated up to 128x128 (for HiDPI screens) looks pretty bad. For F28 and higher I'm going to raise the minimum size to 64x64 which I hope people realize is actually a really low bar. I'm not sure whether to mass file bugs or just try to contact maintainers directly. Affected packages are: abbayedesmorts-gpl alienarena antimicro ardour2 armacycles-ad asylum atanks avogadro BlockOutII balsa banshee barrage bastet boswars btanks btbuilder COPASI-gui camorama cardpeek ccdciel celestia clanbomber colorful crawl-tiles crossfire-client crrcsim curblaster denemo dreampie dsi edb emacs-common-proofgeneral enigma escape flacon fontmatrix freedink-engine freedoom GLC_Player gdesklets geeqie geomorph gkrellm gnofract4d gnome-commander gonvert gpsim gramps groovy gtimelog gvrng gwget hdfview hercstudio hexglass hgview hitori hugin iapetal indistarter k3d key-mon kgpg kgraphviewer kolourpaint lbrickbuster2 libreatlas lpf luminance-hdr Maelstrom mcomix megaglest-data monobristol moserial mtpaint netpanzer nogravity nut-nutrition okteta openstv ostrichriders overgod pdfshuffler peg-solitaire phoronix-test-suite pinball pingus plotdrop portecle pybliographer python3-tools qalculate-gtk qcomicbook qdirstat qgit qjackctl qsynth Ri-li rafkill rocksndiamonds scorched3d screengrab sfxr simple-ccsm sir slashem spectacle supertux tennix tilda tremulous tuxtype2 tvtime tworld ufraw uqm uzbl-defaults valyriatear vavoom-* vdrift virtualplanet wammu xawtv xemacs xmedcon xmoto xpilot-ng xskat xzgv yoshimi Ideas, flames, welcome. Richard. [1] https://github.com/hughsie/appstream-scripts/blob/master/fedora/fedora-rawhide.sh#L9 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-01 at 13:56 -0400, Neal Gompa wrote: > On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > So I think F28/F29 would be best time for retiring YUM. Right now > > DNF > > should be already stable and provide same capabilities (or > > documented > > that something will not be supported). > > > > Hopefully infrastructure / rel-eng folks will finally add support > > for > > rich dependencies[0] which would mean that yum will not work in > > Fedora > > anyway, so.. > > > > Do you still have some critical missing functionality in DNF? And > > let > > us know reasons why would you like to keep YUM available (hopefully > > there are no)! > > > > There is still one thing I've noticed we're missing: API and CLI for > getting package changelogs[1]. This exists in yum but doesn't in dnf. While I agree that this is missing functionality, being honest I think we should educate users to use updateinfo which is meant for users while changelogs might be interested only for developers. Updateinfo is coming from what is written in bodhi. > > In addition, don't we still need yum in the repositories for mock to > target EL6 and EL7 for EPEL? I don't think so, but better to ask developers of mock. > > > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1066867 (CLI RFEs > are > blocked by this bug) > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpsrwACgkQaVcUvRu8 X0yZghAAt1HXXwvgEsYMWYBbCv2wXLwt3tRvdet+FfX+qZFnl0ikdg0wtHdXKzay Ruw5ZKxM5zlIQAEwuBOrNnAOtBFceEo+3JOx65h18LitCALPeWcDhB2H8c6/QlrU kaYtgy6vt7JBntN1KnmGpqv1e2ax4R6f6hXQx+9Is+AmlkU30j/d750NNP/bnL4T X1uN6jU0MS5QYaGvCHxF5vhw16IrQXiJGz/r/LEiYw4Djjur23gOnV32mRVvIcmN +NdpqjOSZXylIO0gKZLIt5BFTAowvakERUp8MVLoacR5RQtjTAucaBcFmjyKBMbe Hq2xq21QXVGqZMh+CK+yjVwyjmiYU9Wmy5yvDyXMy292JBuw1wombEr1DdOGE38i pdSS7gaB5YKLyifRST4+yA9fuhi9gMuNkugKvz8bm4+2tKU88II6COYFwoWVOMHT JKY2l6TKJGY+a+6KYr3vQcTS0AiGI9WjsYZIjpNWanAe7e5B/RdBFgyX/S6j6D3a 3pPc7rUI9J2QZkrKyM/1VDn8zlzfV1DumfsNy+LjfHTohSOADuR6FO3th75f2FP6 gRJbl6EBY0V6ynW+GLn4jlxxxofxYzuVX22G/xyPoPHaklHy0/LrH0GbV4y4EnYN vkEr/BEywW/VmkhWHDKPT6gsnANn4r24TzTdmj60jxfAED3bLpI= =qmL2 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-01 at 13:30 -0500, Ian Pilcher wrote: > On 09/01/2017 12:01 PM, Igor Gnatenko wrote: > > Do you still have some critical missing functionality in DNF? And > > let > > us know reasons why would you like to keep YUM available (hopefully > > there are no)! > > AFAIK there is still no way to get dependency information out of DNF. > (There may be a way to do it, but --verbose certainly doesn't.) This is true and we have plans to implement this, but problem is that we don't know how to represent data. When it is about installing some packages -- it's more or less easy to show, but when upgrades / downgrades are involved it becomes way more complicated. If you have some actual suggestions -- feel free to contact me off list or post them here. ☺ > > -- > = > === > Ian Pilcher arequipeno@gmail. > com > "I grew up before Mark Zuckerberg invented friendship" --- > - > = > === > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmpsygACgkQaVcUvRu8 X0ylbg//SywF5N1LbGWkWg92QfyIW+0sylYNOOLrFnhtRTOQNy1YGOp+1vmTEtU4 5ocM7EjIjoXjlfOMOuhw5EA1bfozdSRiwgnCxrBpxZGRK1UxBuNGcmvN72jd7v+d jDgKsHpYj5HDNwkN6YvqX5YUaUCO0ij2Btq147nZ2dejfQisxsg4+a6Di6gz2JhX 2nk3rd7BBZ0K9l+pX2qQM1QUW4+YBQAEIDpbX8Vy7Y+HA0GDmiTx2cVhjLUhGLqh DSf01bYsQrrYU/lR0/yuPrQ5bq6r7mxIPo1q31AU4mvL2pcmLsa2ZC33O/cyUg6M DQ8TKglFTvbyKeE5Yt1ocvaIL2rBELq0r7Sr10SWTxz0+Z5HUq6PNSvGsSAV7F2K UOtF/Hy0wvCKEi0fhdeZ7inDLRib7JuyM/O5qPzJU1sW6sO17eHPffxyCMXdiCxj ScrJseCE3XLFLp5Z3kxA33iOpT5jQZW+yFqFWVKPE21r4FwQCECzYyMDShfoNYCy RqKZP6rSJu7yBBApcH9Dv1ri23n7eSC5jF+5dKoWwbQ2mbMbuLXf4gkyY2x8C0ZD 4fGzipentKhZZKgqxWEFSLDy8337tWGwH+eJOx/8adomNLiXev7BSD3wBHfOsjkn kxHq+8Y+PG/HodZKzsvW37g1V+ELcFfIyxmp/2vC1WouG9Xltx8= =rUQv -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On Fri, Sep 01, 2017 at 09:19:24PM +0200, Igor Gnatenko wrote: > > There is still one thing I've noticed we're missing: API and CLI for > > getting package changelogs[1]. This exists in yum but doesn't in dnf. > While I agree that this is missing functionality, being honest I think > we should educate users to use updateinfo which is meant for users > while changelogs might be interested only for developers. Updateinfo is > coming from what is written in bodhi. RPM specfile changelogs are often of interest to systems administrators. I'd love to get the bodhi info to always include everything that would be useful in that way, but in practice it's really not so. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Raising requirement for application icons in GNOME Software
At the moment the appstream-builder requires a 48x48px application icon[1] to be included in the AppStream metadata. I'm sure it's no surprise that 48x48 padded to 64x64 and then interpolated up to 128x128 (for HiDPI screens) looks pretty bad. Instead: magnify by 3x linear pixel replication (48 -> 144), then take some 128x128 subset such as the center or upper-left. Yes, losing 16 pixels width will be unfortunate, but it is a better default because it looks nicer. The part that is retained will not be distorted, which is more usable until the apps supply 128x128. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On 09/01/2017 02:21 PM, Igor Gnatenko wrote: This is true and we have plans to implement this, but problem is that we don't know how to represent data. When it is about installing some packages -- it's more or less easy to show, but when upgrades / downgrades are involved it becomes way more complicated. If you have some actual suggestions -- feel free to contact me off list or post them here. ☺ I won't claim to be a huge fan of the way that yum insisted on spewing detailed dependency information, but it did provide the information require to answer those "Why does Inkscape require mdadm?" type questions. I would think that format could be a starting point (shown only when --verbose or some other option is used). As far as I remember, yum shows this information for both installs and upgrades; I'm not sure about downgrades. -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
Hi, /*Igor Gnatenko*/ wrote on Fri, 01 Sep 2017 19:01:49 +0200: <..> Do you still have some critical missing functionality in DNF? And let us know reasons why would you like to keep YUM available (hopefully there are no)! I've not tried 'dnf remove --duplicates' yet, but if it behaves similar to 'dnf remove --assumeno $(dnf -C repoquery --duplicated --latest-limit -1 -q)', then there is still no 'sane' way to remove duplicated packages, which might be needed if 'dnf upgrade' is terminated half-way. There is also a RFE at [1] for such scenarios, but it would be enough is 'dnf remove --duplicates' doesn't try to remove other packages as dependencies of duplicated packages, or even better, if 'dnf upgrade' is able to 'sanely' continue a terminated 'dnf upgrade' operation instead of complaining about conflicts and being unable to proceed. Currently, the user must know that the problem is duplicated packages, and learn how to safely remove them without removing other required stuff. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1091702 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On Fri, 2017-09-01 at 15:00 -0500, Ian Pilcher wrote: > On 09/01/2017 02:21 PM, Igor Gnatenko wrote: > > This is true and we have plans to implement this, but problem is > > that > > we don't know how to represent data. When it is about installing > > some > > packages -- it's more or less easy to show, but when upgrades / > > downgrades are involved it becomes way more complicated. > > > > If you have some actual suggestions -- feel free to contact me off > > list > > or post them here. ☺ > > I won't claim to be a huge fan of the way that yum insisted on > spewing detailed dependency information, but it did provide the > information require to answer those "Why does Inkscape require > mdadm?" type questions. The old repoquery had a --tree-requires option which was really great for this. (along with a few other --tree-* options) -- Mathieu ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On Friday, 1 September 2017 21:30:44 CEST Matthew Miller wrote: > RPM specfile changelogs are often of interest to systems > administrators. Agreed. Before I update a huge number of hosts I'd like to check the changelogs for any possible trouble. This is the the main thing I miss in dnf right now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Build weirdness
Hi I've got another weird situation: I wanted to get pjproject building again, rebased and added necessary patches, did the scratch build, and all looked good [1]. So I went ahead and committed the result, fired off the build, but to my surprise that build failed while applying the patches [2]. I thought maybe upstream did a respin of the source tarball and that I was using another one that what was uploaded with fedpkg new-source, so I did a fedpkg sources, and for some reason that also downloaded obsolete version of some of the patches: $ fedpkg sources Downloading pjproject-2.6.tar.bz2 100.0% Downloading pjproject-aarch64.patch 100.0% Downloading pjproject-armv7.patch 100.0% Downloading pjproject_config_site.patch 100.0% Downloading pjproject_fixup_pc_file.patch 100.0% Downloading pjproject_no_third_party.patch 100.0% Downloading pjproject-ppc64.patch 100.0% I suspect that this is why the build are failing, because it is still using the obsolete patches, and not what I committed [3]. Any idea what's going on here? Thanks Sandro [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=21611422 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=21608502 [3] https://src.fedoraproject.org/rpms/pjproject/tree/master ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] Fedora 27 Branched 20170901.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 27 Branched 20170901.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/27 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170901.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170901.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170901.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170901.n.1_User:Adamwill/NoMoreAlpha/Server https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170901.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170901.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170901.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_27_Branched_20170901.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
/*Igor Gnatenko*/ wrote on Fri, 01 Sep 2017 15:19:34 +0200: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2017-09-01 at 16:01 +0300, Marius Vollmer wrote: Neal Gompa writes: Implement your AppStream filter at the application level, rather than messing with appstream-data package. Yes, of course. Cockpit will do the right thing even with the full appstream-data package. This is only about not having 15 MiB of useless data installed. Just check how much data you download for repository metadata.. 😉 15MiB can be important if you want to have a cockpit container (in which you won't store repo metadata too). And I still hope Fedora repository metadata madness (which has become even worse as tools evolved!) will be fixed/improved one day... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [SO-NAME BUMP] Updating jsoncpp on Rawhide and fc27
Am 28.08.2017 um 22:28 schrieb Björn 'besser82' Esser: Hello folks, I'm planning to update jsoncpp on Rawhide and fc27 during the next days. After the builds have landed, I'll take care of rebuilding all consumers against the new so name. Since the API / ABI has no publicly consumed symbols removed, I don't expect any real problems. Cheers, Björn I've updated jsoncpp to v1.8.3 for Rawhide and fc27, which bumps the DSO to libjsoncpp.so.19. No public symbols removed, just some added. According to `dnf --releasever=rawhide repoquery --whatrequires 'libjsoncpp.so.11*'` I will (or need to) rebuild the following packages during tonight: ### Single Builds * cmake (twice, first "no gui" for bootstrap to unbreak circular deps with Qt, second "gui enabled") * kopete * libjson-rpc-cpp * minetest * orthanc * paraview * passenger * vfrnav * vrpn ### Chain builds vtk : engrid pcl : mrpt The update to fc27 will get pushed, as soon as I finished rebuilding all named packages. Cheers, Björn ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Build weirdness
On Fri, Sep 01, 2017 at 10:56:39PM +0200, Sandro Mani wrote: > Hi > > I've got another weird situation: I wanted to get pjproject building > again, rebased and added necessary patches, did the scratch build, > and all looked good [1]. So I went ahead and committed the result, > fired off the build, but to my surprise that build failed while > applying the patches [2]. I thought maybe upstream did a respin of > the source tarball and that I was using another one that what was > uploaded with fedpkg new-source, so I did a fedpkg sources, and for > some reason that also downloaded obsolete version of some of the > patches: > > $ fedpkg sources > Downloading pjproject-2.6.tar.bz2 > > 100.0% [...] > I suspect that this is why the build are failing, because it is > still using the obsolete patches, and not what I committed [3]. > > Any idea what's going on here? I think you've basically analyzed it correctly. The patches have been added to the ‘sources’ file (and so are pulled from the lookaside cache). This is of course wrong. The new patches are in git, but these are overwritten by the lookaside cache. The easiest thing is to simply edit the ‘sources’ file and remove all the lines from it which mention a patch -- in the currently checked in ‘sources’ file basically all the lines except the very first one. It should work after you commit that change. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Build weirdness
I think you've basically analyzed it correctly. The patches have been added to the ‘sources’ file (and so are pulled from the lookaside cache). This is of course wrong. The new patches are in git, but these are overwritten by the lookaside cache. The easiest thing is to simply edit the ‘sources’ file and remove all the lines from it which mention a patch -- in the currently checked in ‘sources’ file basically all the lines except the very first one. It should work after you commit that change. Ah indeed, I forgot to look at the actual sources file, I just looked what was marked as Source in the spec. Thanks for the hint! Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Urgent attention required; ImageMagick update breakage
On 09/01/2017 01:13 PM, Adam Williamson wrote: FESCo decided at today's meeting that 7 should not go to F27 (unless it can be made parallel installable and not used by anything release- blocking by default), and to go into F28 there must be a system-wide Change: The libs are definitely parallel installable. The binaries share a name so we could use alternatives and default to version 6. Thoughts? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On Fri, 2017-09-01 at 13:30 -0500, Ian Pilcher wrote: > On 09/01/2017 12:01 PM, Igor Gnatenko wrote: > > Do you still have some critical missing functionality in DNF? And > > let > > us know reasons why would you like to keep YUM available (hopefully > > there are no)! > > AFAIK there is still no way to get dependency information out of DNF. > (There may be a way to do it, but --verbose certainly doesn't.) Exactly the reason why I am still using yum-deprecated for updates on rawhide, especially for hairy monster bumps like icu, boost, perl etc.. - Yanko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
On Sep 1, 2017 3:31 PM, "Matthew Miller" wrote: On Fri, Sep 01, 2017 at 09:19:24PM +0200, Igor Gnatenko wrote: > > There is still one thing I've noticed we're missing: API and CLI for > > getting package changelogs[1]. This exists in yum but doesn't in dnf. > While I agree that this is missing functionality, being honest I think > we should educate users to use updateinfo which is meant for users > while changelogs might be interested only for developers. Updateinfo is > coming from what is written in bodhi. RPM specfile changelogs are often of interest to systems administrators. I'd love to get the bodhi info to always include everything that would be useful in that way, but in practice it's really not so. Also, non Fedora repositories do not publish update info, as there is no tool I'm aware of that lets you make it without Bodhi. If for nothing else, change logs are all we have for them. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: FAILED: BuildError: package ... not in list for tag f28-pending
On 09/01/2017 12:46 PM, Tom Hughes wrote: > On 01/09/17 17:26, Michael Schwendt wrote: >> On Thu, 31 Aug 2017 22:14:11 +0200, Björn 'besser82' Esser wrote: >> It's been several hours since this entirely new package repo has been created, but the koji build still fails. How long does it take for koji to learn about this new package? >> >>> it takes as long someone from releng tells Koji manually about it… It >>> can take up to one day. >> >> What a surprise! Why is it a separate procedure from the repository >> creation step? Could a status update be added to the ticket that one >> opens? > > Well as I understand it the idea is that it should happen automatically > but there is a bug that has yet to be tracked down and hence it is > currently being done manually when the automatic update fails. Right. This is absolutely not the intended process. There are two scripts here: 1) A script that listens for fedmsgs on new package or branch creation and also syncs this to koji. 2) A script runs once a day and syncs all packages to koji. Script 1 isn't working and we haven't determined why (but we did add a bunch of debugging to it a few days ago, so it should be fixed post flock I would expect). If you can wait a day things should be fine. Otherwise, I'm happy to manually sync packages to lessen any blockage or delay for people. Hope that makes sense... 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
