Re: GnuPG 2.2.0 and replacement of GnuPG1
On 09/04/2017 08:56 AM, Remi Collet wrote: > gnupg v2 is a nightmare for "server", I maintain some PHP extensions and > libraries which works perfectly against v1, and not against v2 > > And, AFAIK, v1 is still maintained. $ date|gpg2 --passphrase aaa -ca This shows a popup asking me for a passphrase, while it works perfectly on gpg v1. ??? -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
On Friday, September 1, 2017 12:16:32 PM CEST Michal Novotny wrote: > On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) > > 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. Sure, real world example [1]. There's no Makefile in the root directory (and I don't even plan to propose adding it as that's java project, so 'make srpm' is sort of no-go). We agreed with upstream on the (super-ugly btw.) directory structure under packaging/rpm; I hope this is one day to be replaced by trivial: packaging/rpm/generate-srpm.sh packaging/rpm/spec.template > Well, we can continue discussion e.g. also in PRs if people are interested > in this. Accepted, though I thought that we could s/make srpm/any command/ right now to avoid spending additional bucks later with the PRs. Likely, once the new build method is added we'll maintain it forever so the bad decision is not completely free of charge. [1] https://github.com/pgjdbc/pgjdbc Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GnuPG 2.2.0 and replacement of GnuPG1
On Sun, 2017-09-03 at 13:45 +0200, Igor Gnatenko wrote: > GnuPG 2.2.0 has --enable-gpg-is-gpg2 which would install compat > symlink > from /usr/bin/gpg to /usr/bin/gpg2.. > > Is it time to retire gnupg (v1) ? I really do not care. If the gpg v1 is still maintained upstream and there is somebody willing to maintain the Fedora package, I think we can keep the situation as is. This does not apply to RHEL/CentOS where we already ship gpg2 with the compat symlinks. -- Tomáš Mráz Red Hat No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] * Google and NSA associates, this message is none of your business. * Please leave it alone, and consider whether your actions are * authorized by the contract with Red Hat, or by the US constitution. * If you feel you're being encouraged to disregard the limits built * into them, remember Edward Snowden and Wikileaks. ___ 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
On 1 September 2017 at 20:47, John Reiser wrote: > Yes, losing 16 pixels width will be unfortunate, but it is a > better default because it looks nicer. I've tried this, and the "cropped" icons look much worse than the padded ones. Plus, multiplying by 3 is a much more expensive thing to do on lots of pixbufs, as it's not a power of two and can't be done using a bitshift. This is also the reason we pre-render the SVGs; showing ~100 64x64 icons "instantly" isn't an easy thing to do when you're using rsvg. Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
Dne 2.9.2017 v 16:00 Neal Gompa napsal(a): 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 one other feature I just recalled: arbitrary yum vars for substitution. DNF only supports substituting releasever and basearch, while yum allowed for you to define custom variables in /etc/yum/vars. Scientific Linux and a few other distributions depend on it, and there are people who use it in local installations for offering things like login credentials, applicaton tokens, and things like that for secure repository access. Hi What I see critical on this plan is - when I use Rawhide daily it's not uncommon totally UNTESTED dnf lands in repo - and yum is then the only 'easy' way to handle such case without any complexity. So will be there ANY protection to insert untested core package like dnf is into repo which is IN USE by users ?? Not to mentioning - yum had at least 'yum-complete-transaction' while dnf is basically useless when upgrade transaction is aborted for whatever reason you can think of Regards Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F26 and kernel-4.13
Hi guys, my question: is it planned to make and release kernel-4.13 for F26? I saw that it has been declared as mainline and stable on kernel.org. Kind regards Joachim Backes -- Fedora release 26 (Twenty Six) Kernel-4.12.9-300.fc26.x86_64 Joachim Backes https://www-user.rhrk.uni-kl.de/~backes/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
Dne 1.9.2017 v 22:10 Hedayat Vatankhah napsal(a): > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1091702 This is blocker for me as well. Mirek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 and kernel-4.13
It can be when 4.13.3-4.13.5 released. пн, 4 сент. 2017 г. в 12:40, Joachim Backes : > Hi guys, > > my question: is it planned to make and release kernel-4.13 for F26? I > saw that it has been declared as mainline and stable on kernel.org. > > Kind regards > > Joachim Backes > > -- > > Fedora release 26 (Twenty Six) > Kernel-4.12.9-300.fc26.x86_64 > > > Joachim Backes > https://www-user.rhrk.uni-kl.de/~backes/ > ___ > 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: RFC: retiring yum
Dne 1.9.2017 v 19:56 Neal Gompa napsal(a): > On Fri, Sep 1, 2017 at 1: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)! >> > > In addition, don't we still need yum in the repositories for mock to > target EL6 and EL7 for EPEL? > > Shouldn't the --bootstrap-chroot fix this? It does not work terribly well ATM, but it could hopefully be improved. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
Dne 2.9.2017 v 16:00 Neal Gompa napsal(a): > 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 one other feature I just recalled: arbitrary yum vars for > substitution. DNF only supports substituting releasever and basearch, > while yum allowed for you to define custom variables in /etc/yum/vars. > Scientific Linux and a few other distributions depend on it, and there > are people who use it in local installations for offering things like > login credentials, applicaton tokens, and things like that for secure > repository access. > > Interesting. I already requested something like this previously [1], but had not good enough use case for it ... May be you want to recycle my ticket? Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=1211253 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Verifying sources against gpg signature during RPM build ?
A number of packages that I maintain have GPG signatures provided alongside the sources for new releases. Is there any best pratice approach / RPM macro magic for verifying the GPG signature of sources during build, or are packagers just (re)inventing the wheel each time ? 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: Non-responsive maintainer process for caillon, and retiring xchat
Dne 31.8.2017 v 13:14 Debarshi Ray napsal(a): > On Mon, Jun 26, 2017 at 11:06:16AM +, Debarshi Ray wrote: >> On Wed, Jun 14, 2017 at 03:19:52PM +, Debarshi Ray wrote: >>> I would like to initiate the non-responsive maintainer process [1] for >>> Christopher Aillon [2]. A long time ago, he used to be part of the >>> Fedora and Red Hat desktop teams. He is no longer around. He left >>> software development and was last seen living off the grid in Hawaii >>> [3]. Therefore I have jumped straight to the fourth step in the >>> aforementioned process. >>> >>> Here is a list of his packages: >>> https://admin.fedoraproject.org/pkgdb/packager/caillon/ >>> >>> I am particularly interested in xchat, which I want to retire right >>> after removing Chris as the point of contact for his packages. >> Filed: https://pagure.io/fesco/issue/1721 > This is done - caillon has been removed as the point-of-contact for > his packages, and xchat has been retired from the f27 and master > branches. Unfortunately, you have missed this dependency: https://bugzilla.redhat.com/show_bug.cgi?id=1486752 Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Build weirdness
Dne 1.9.2017 v 22:56 Sandro Mani napsal(a): > 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 Are you aware about "fedpkg import"? Much better choice for uploading sources IMO. Vít ___ 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
Hi, On Fri, Sep 1, 2017 at 9:12 PM, Richard Hughes wrote: > 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. > Most maintainers are not graphic artists. Moreover if they had available an higher resolution icon, they would already ship it. I also don't think that nagging upstream about these missing icons is really welcome - most of the times even upstream doesn't have a graphic artist available. I believe the correct way to solve this issue is that Fedora Design team (if available) provides new icons to upstream. This can be a long process and therefore I don't think it is safe to raise the minimum size requirement to 64x64 any time soon. Bye, Andrea ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Build weirdness
On 04.09.2017 12:42, Vít Ondruch wrote: Dne 1.9.2017 v 22:56 Sandro Mani napsal(a): 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 Are you aware about "fedpkg import"? Much better choice for uploading sources IMO. Yes (actually I didn't know there existed anything else), but the issue here was what was already in the sources file, not uploading new stuff. Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Self Introduction: Jens Reimann
Hi, I've been working with Linux since around 1999. And around that time I started creating a few RPM packages for Red Hat Linux, so that they would easily install. Over time I got "distracted" with Ubuntu and Java. Working since around 2007 on open source projects, in the last years mainly for IoT and Eclipse Foundation projects. Now that brought me back to RPM packaging, my motivation is to bring "open62541" and "Eclipse 4DIAC" to RPM and hopefully Fedora. I started with a request for "opne62541" [1], which is an OPC UA protocol implementation, which is interesting for people doing IoT and Industry 4.0. >From what I understood the request is already reviewed and approved. Cheers Jens [1] https://bugzilla.redhat.com/show_bug.cgi?id=1487578 -- Jens Reimann Senior Software Engineer / EMEA ENG Middleware Werner-von-Siemens-Ring 14 85630 Grasbrunn Germany phone: +49 89 2050 71286 _ Red Hat GmbH, www.de.redhat.com, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Verifying sources against gpg signature during RPM build ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2017-09-04 at 11:29 +0100, Daniel P. Berrange wrote: > A number of packages that I maintain have GPG signatures provided > alongside > the sources for new releases. Is there any best pratice approach / > RPM macro > magic for verifying the GPG signature of sources during build, or are > packagers just (re)inventing the wheel each time ? There is some draft[0] available, but I can't find FPC ticket on it. > > 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 :| > [0] https://fedoraproject.org/wiki/PackagingDrafts:GPGSignatures - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmtNhAACgkQaVcUvRu8 X0zULg/+NFtXY54w+MEmkv8OHCyXvHnyMhJWKLYnNIncs7pwBuVWWS6ZbxfcbEXC 7r+lKlhRmMEDbnmW8P4lzSzfNh3njiq8MH23w6DT6m9bbh+UeSYoZ49lFoARM63X ltNtcHd53h8+8CcX7I5WdlWY48wqwZZU/qYU7pE0ZvyPrt0l53IFGujjUw76bDdm H0VyM1F4tVW0Tae+uIwtK1woQEN4uGigHBR3KYatEi/xdKnCEriWL2gS7IZrn3Ek vddr7hXaNWuUid79SxsYvA6Q4gpEBLlRrCpeTVCJgTZhY9bIkghfid4p3ZA022sS TZAVvwYGC94DOePTOvxERZLp1wNZzxQRXBGdxMryVwetZK+d+qHc+Bb+owx7fTVg WBLTnp48G/KCLWiVyV817fq/S8Nn/jqucF3ool3k91DDD4McNFYGqigqflYe41jy 9hLP6Pzb7RCxR2Nk+pZrfe8Zwk6DRO3Y6sZuFQTBVgxyxinIaEQ+kXOreW6wXi7J mgvJ0QD4X8+i5++yMFPBau5PQxdojJm/rzYLm9ePJsUdS/vg0tx2sLUh2YVwsbC9 rRlLN7ziegv7YCJK1uDi60QwOzRLgRWwKUVhj5MNKPlUMXaepOFj3nt66j+jBD/U Be18rCG6vJAR4796Gziy8a+ueu2rN3F+QiIYvm9EtuWz/DZzwP0= =Epz5 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 and kernel-4.13
On Mon, Sep 4, 2017 at 10:39 AM, Joachim Backes wrote: > Hi guys, > > my question: is it planned to make and release kernel-4.13 for F26? I saw > that it has been declared as mainline and stable on kernel.org. The latest stable kernel will always go to the latest stable Fedora release (n-1 depends a little where in the cycle it is before EOL) and the general rule of thumb is around the .2 release but might be a little later depending on stability (4.12 was later for example). ___ 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 3:10 PM, Hedayat Vatankhah wrote: > 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. > I have to agree here... It happened to me with an upgrade. I got bit by some bug where the screen was blank but the upgrade was actually happening. I didn't see much in the way of disk activity so I force rebooted the machine. It actually booted but I had a bunch of duplicate packages since most of the f26 packages had installed but the f25 (and 24) packages didn't get cleaned up. I tried using 'dnf repoquery --duplicated > duplicates.log' and then cat'ing that to dnf remove with xargs (grepping for fc25) but it wanted to remove a bunch of dependent packages. I ended up having the use 'rpm -e --nodeps' to get rid of the duplicate packages and then a 'dnf distro-sync' got me pretty much fixed up. On a side note, I also updated an old laptop and I did not interrupt the upgrade process but I still ended up with a lot of duplicate packages... Not sure how that happened. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Non-responsive maintainer process for caillon, and retiring xchat
Hey, On Mon, Sep 04, 2017 at 12:32:38PM +0200, V??t Ondruch wrote: > Unfortunately, you have missed this dependency: > > https://bugzilla.redhat.com/show_bug.cgi?id=1486752 Yes, sorry for missing it initially. However, I emailed konr...@fedoraproject.org last Thursday after you pinged me on IRC. Thanks for catching this! Cheers, Rishi ___ 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.
On 2017-09-01, Carlos O'Donell wrote: > 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-*. > What if there is a bug in the behavior of the frozen base-* packages? Do we have to live with the bug for the rest of the life time of the base (=platform)? Or do we break this rule and replace the broken package with a patched one? If the second one is the answer, do we know how it will affect packages whose build script does run-time checks (i.e. every ./configure script) to tune compile-time options? More strictly speaking, will we be adding new features into the same stream of the base module? I guess we won't. Otherwise we have to update the frozen base-* packages accordingly to make the new features available at build-time of packages that want to use the new features. -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Non-responsive maintainer process for caillon, and retiring xchat
Dne 4.9.2017 v 13:40 Debarshi Ray napsal(a): > Hey, > > On Mon, Sep 04, 2017 at 12:32:38PM +0200, V??t Ondruch wrote: >> Unfortunately, you have missed this dependency: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1486752 > Yes, sorry for missing it initially. However, I emailed > konr...@fedoraproject.org last Thursday after you pinged me on IRC. > > Thanks for catching this! > > Cheers, > Rishi Ah, I'd been on PTO and now I see I missed your reply on IRC. Sorry for that. BTW xchat-tcl was subpackage coming from of xchat SRPM, so that should be OK. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: RFC: retiring yum
- Original Message - > From: "Pete Travis" > To: "Development discussions related to Fedora" > > Sent: Saturday, September 2, 2017 4:08:54 PM > Subject: Re: RFC: retiring yum > > > > On Sep 1, 2017 4:54 PM, "Kai Bojens" < k...@kbojens.de > wrote: > > > > 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. > > +1, as a system administrator I often use repoquery or the yum plugin to get > changelogs. This is especially useful when demonstrating that a particular > CVE has been mitigated in a given envr. Utility that enables compliance is > very valuable for my use case. > > -- Pete > Recently I wrote a simple bash script[1] to get new changelog entries for a dnf update. [1] https://github.com/pvalena/scripts/blob/master/getupchangelog Regards, Pavel Valena Associate Software Engineer, RED HAT ___ 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
Michael , I move thread to here [1] [1] https://pagure.io/fesco/issue/1766 On Sun, 2017-09-03 at 16:13 +0100, Sérgio Basto wrote: > On Sat, 2017-09-02 at 14:10 -0500, Michael Cronenworth wrote: > > On Sep 2, 2017 11:36 AM, Adam Williamson > g> > > wrote: > > So I'm gonna start working on the 6.9.9 downgrade in F27, and I'm > > tempted to just downgrade Rawhide at the same time, and if we > > actually > > do decide to try 7 again, we can start over at that time. Do you > > agree > > with that plan? Thanks! (It doesn't change anything about the > > required > > epoch bumps, because even if we did 6.9.9 in F27 and stayed with 7 > > in > > Rawhide, we'd need to bump the epoch on *both* to ensure Rawhide's > > 7 > > was ahead of F27's 6). > > > > Based on the response from ImageMagick let's rebuild for version 6 > > in > > F27+. We should keep 7, but as ImageMagick7 instead. > > Well if we go to have ImageMagick6 and ImageMagick7 in F27+ and > since > ImageMagick7 should be the main package, in my point of view , we > should add ImageMagick6 package and maintain ImageMagick as is , > like, > for example, openssl-1.1 and compat-openssl10 . > > Cheers, > -- > Sérgio M. B. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Nvme APST Quirk
Hi,
Apologies if this is the incorrect medium in which to send patches.
There is a significant issue with the apst code that has been merged for
the nvme driver under kernels >= 4.11 . The issue impacts some versions of
Samsung’s firmware on sm961/pm961 and 960 nvme drives. The issue causes the
drive to go into ‘deep sleep’ without warning and no way of bringing the
interface back up.
Historically this issue has been reported against specific dell
hardware and there has been a hunk of code to check for the presence
of that hardware before calling NVME_QUIRK_NO_DEEPEST_PS. However I
can confirm that with nvme apst support merged this issue arises with
multiple mainboards. This is a critical issue because it can result in
data loss, the way in which the issue manifests does not alert the
user to the fact that the drive has dropped off.
There is however an extremely simple fix – just call the
NVME_QUIRK_NO_DEEPEST_PS quirk unconditionally with this hardware.
From: Dominic Robinson
Date: Fri, 1 Sep 2017 15:38:44 +0100
Subject: Turn off deepest power saving mode for pm961 drives
diff -aurN a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
--- a/drivers/nvme/host/pci.c 2017-07-03 00:07:02.0 +0100
+++ b/drivers/nvme/host/pci.c 2017-09-01 15:38:44.041550898 +0100
@@ -2302,6 +2302,8 @@
.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
{ PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */
.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
+ { PCI_DEVICE(0x144d, 0xa804), /* Samsung pm961 */
+ .driver_data = NVME_QUIRK_NO_DEEPEST_PS, },
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xff) },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001) },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2003) },
I have already filed a bug report – not getting a response:
https://bugzilla.redhat.com/show_bug.cgi?id=1487421
I can confirm this patch works – I’d really like to get it merged, as of
right now there are no available kernels in Fedora 26 that are immune to
this issue.
Kind Regards,
Dominic Robinson
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
heads up: poppler soname bump
Hi,
I will build a new release of poppler this week, which includes soname
bump. I will take care of rebuilding the affected packages:
boomaga
calligra
cups-filters
evas-generic-loaders
gambas3
gdal
gdcm
inkscape
kf5-kfilemetadata
libreoffice
okular
pdf2djvu
poppler-sharp
texlive
texworks
Note that packages that only use one of the wrappers (poppler-cpp,
poppler-glib, poppler-qt{4,5}) are not affected.
D.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
I apologize for late response as I was on holiday. Not sure if you already talked together about that but I agree with Pavel. `make srpm` solves only _one_ type of troubles. I guess that usually I will get response from upstream like that: -- we will not add Makefile just because of COPR that is not important for us in any way -- we will not modify Makefile just because of... etc. It would work for us where we are upstream, but it is just another mess next to _setup.py_ for example. Really, the possibility of own script inside copr is much more convenient, it is more generic solution and covers many more troubles. Personally from my point of view, I would rather invest (e.g.) one more week to generic solution than save that time for partial solution. But I don't see into the COPR and I will not work on it so I am not saying that it has to be done in that way. On 4.9.2017 09:47, Pavel Raiskup wrote: > On Friday, September 1, 2017 12:16:32 PM CEST Michal Novotny wrote: >> On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) >>> 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. > > Sure, real world example [1]. There's no Makefile in the root directory (and > I > don't even plan to propose adding it as that's java project, so 'make srpm' is > sort of no-go). > > We agreed with upstream on the (super-ugly btw.) directory structure under > packaging/rpm; I hope this is one day to be replaced by trivial: > > packaging/rpm/generate-srpm.sh > packaging/rpm/spec.template > >> Well, we can continue discussion e.g. also in PRs if people are interested >> in this. > > Accepted, though I thought that we could s/make srpm/any command/ right now to > avoid spending additional bucks later with the PRs. Likely, once the new > build > method is added we'll maintain it forever so the bad decision is not > completely > free of charge. > > [1] https://github.com/pgjdbc/pgjdbc > > Pavel > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- Petr Stodulka Core Services (In-place upgrades and migrations) IRC nicks: pstodulk, skytak Red Hat signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Nvme APST Quirk
On Mon, Sep 4, 2017 at 9:28 AM, Dominic Robinson wrote:
> Hi,
>
>
>
> Apologies if this is the incorrect medium in which to send patches.
>
>
>
> There is a significant issue with the apst code that has been merged for the
> nvme driver under kernels >= 4.11 . The issue impacts some versions of
> Samsung’s firmware on sm961/pm961 and 960 nvme drives. The issue causes the
> drive to go into ‘deep sleep’ without warning and no way of bringing the
> interface back up.
>
>
>
> Historically this issue has been reported against specific dell hardware and
> there has been a hunk of code to check for the presence of that hardware
> before calling NVME_QUIRK_NO_DEEPEST_PS. However I can confirm that with
> nvme apst support merged this issue arises with multiple mainboards. This is
> a critical issue because it can result in data loss, the way in which the
> issue manifests does not alert the user to the fact that the drive has
> dropped off.
>
>
>
> There is however an extremely simple fix – just call the
> NVME_QUIRK_NO_DEEPEST_PS quirk unconditionally with this hardware.
>
>
>
> From: Dominic Robinson
>
> Date: Fri, 1 Sep 2017 15:38:44 +0100
>
> Subject: Turn off deepest power saving mode for pm961 drives
>
> diff -aurN a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
>
> --- a/drivers/nvme/host/pci.c 2017-07-03 00:07:02.0 +0100
>
> +++ b/drivers/nvme/host/pci.c 2017-09-01 15:38:44.041550898 +0100
>
> @@ -2302,6 +2302,8 @@
>
>.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
>
> { PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */
>
>.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
>
> + { PCI_DEVICE(0x144d, 0xa804), /* Samsung pm961 */
>
> + .driver_data = NVME_QUIRK_NO_DEEPEST_PS, },
>
> { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xff) },
>
> { PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001) },
>
> { PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2003) },
>
>
>
> I have already filed a bug report – not getting a response:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1487421
>
>
>
> I can confirm this patch works – I’d really like to get it merged, as of
> right now there are no available kernels in Fedora 26 that are immune to
> this issue.
This needs to be submitted and merged into the upstream kernel. Your
patch is missing a good changelog describing the problem, and the
Signed-off-by line required for all kernel patches.
josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Test-Announce] 2017-09-04 (**TODAY**)! @ 16:00 UTC - Fedora 27 Blocker Review Meeting
# F27 Blocker Review meeting # Date: 2017-09-04 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We currently have 7 proposed Beta blockers and 3 proposed Final blockers to review, so let's have a Fedora 27 blocker review meeting. Apologies for the late notice, but we're going to try and run it at the top of the hour (in 45 minutes), if enough folks show up. If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F27 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good day and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ 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 Sun, 2017-09-03 at 16:13 +0100, Sérgio Basto wrote: > On Sat, 2017-09-02 at 14:10 -0500, Michael Cronenworth wrote: > > On Sep 2, 2017 11:36 AM, Adam Williamson > > wrote: > > So I'm gonna start working on the 6.9.9 downgrade in F27, and I'm > > tempted to just downgrade Rawhide at the same time, and if we > > actually > > do decide to try 7 again, we can start over at that time. Do you > > agree > > with that plan? Thanks! (It doesn't change anything about the > > required > > epoch bumps, because even if we did 6.9.9 in F27 and stayed with 7 > > in > > Rawhide, we'd need to bump the epoch on *both* to ensure Rawhide's 7 > > was ahead of F27's 6). > > > > Based on the response from ImageMagick let's rebuild for version 6 in > > F27+. We should keep 7, but as ImageMagick7 instead. > > Well if we go to have ImageMagick6 and ImageMagick7 in F27+ and since > ImageMagick7 should be the main package, in my point of view , we > should add ImageMagick6 package and maintain ImageMagick as is , like, > for example, openssl-1.1 and compat-openssl10 . Nope, that's exactly the opposite of what FESCo agreed: IM7 can only go in as the *variant* package, not the main one. The main one must be IM6. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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 Sun, 2017-09-03 at 10:32 +0200, Ralf Corsepius wrote: > > This could makessome sense, if these are really used and if > vulnerabilities can be reacted upon/fixed in the old versions. > > If the latter doesn't apply, it would be better to those remove package > which requires these old libs from the distro. The 6 series is still maintained upstream at present, as discussed earlier. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net 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
El vie, 01-09-2017 a las 21:19 +0200, Igor Gnatenko escribió: > 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. yes we do need yum to be around until RHEL 7 goes EOL Dennis > > [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 > > ___ > 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: GnuPG 2.2.0 and replacement of GnuPG1
On Mon, Sep 04, 2017 at 09:23:05AM +0200, Roberto Ragusa wrote: > $ date|gpg2 --passphrase aaa -ca > > This shows a popup asking me for a passphrase, while it works > perfectly on gpg v1. You need to add --batch to the command line: $ LANG=C date|gpg2 --batch --passphrase aaa -ca | gpg2 --batch --passphrase aaa gpg: AES encrypted data gpg: encrypted with 1 passphrase Mon Sep 4 18:12:56 CEST 2017 Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GnuPG 2.2.0 and replacement of GnuPG1
On Sun, Sep 03, 2017 at 01:45:40PM +0200, Igor Gnatenko wrote: > GnuPG 2.2.0 has --enable-gpg-is-gpg2 which would install compat symlink > from /usr/bin/gpg to /usr/bin/gpg2.. > > Is it time to retire gnupg (v1) ? It would be great if we could make gpg2 as the default (add symlink from /usr/bin/gpg to /usr/bin/gpg2) and move gpg1 to /usr/bin/gpg1. Debian beat us to this. I was also thinking about proposing this as a new Systemwide Change. Would you be willing to co-own this feature with me? Kind regards Till ___ 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
El vie, 01-09-2017 a las 13:37 +0300, Marius Vollmer escribió: > 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". > The correct way to deal with appstream is to add the appstream data to rpm headers and then teach createrepo to make the appropriate metadata files. you would then have appropriate appdata in the server, workstation etc repos, with per module repos you could have apppropriately limited repos or we cwould need to make changes to mirrormanager, how we build and ship updates, and limit users to appropriate Server etc repos. the hack of how we build and ship it today works but has a lot of issues with Race conditions etc. Dennis ___ 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 21:19 +0200, Igor Gnatenko wrote: > 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. But developers use yum/dnf too. I need to look up package changelogs *all the time*, and I hate it every time I run 'dnf repoquery -- changelog foo' and think 'oh yeah, that doesn't work'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GnuPG 2.2.0 and replacement of GnuPG1
On 09/04/2017 06:13 PM, Till Maas wrote: > On Mon, Sep 04, 2017 at 09:23:05AM +0200, Roberto Ragusa wrote: > >> $ date|gpg2 --passphrase aaa -ca >> >> This shows a popup asking me for a passphrase, while it works >> perfectly on gpg v1. > > You need to add --batch to the command line: > $ LANG=C date|gpg2 --batch --passphrase aaa -ca | gpg2 --batch --passphrase > aaa > gpg: AES encrypted data > gpg: encrypted with 1 passphrase > Mon Sep 4 18:12:56 CEST 2017 You are right, but existing scripts do not expect this, especially if they are calling "gpg" and getting gpg2. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GnuPG 2.2.0 and replacement of GnuPG1
On Mon, Sep 04, 2017 at 08:56:31AM +0200, Remi Collet wrote: > gnupg v2 is a nightmare for "server", I maintain some PHP extensions and > libraries which works perfectly against v1, and not against v2 Would it be ok for you to patch the libraries to use /usr/bin/gpg1 instead? > And, AFAIK, v1 is still maintained. It is on life-support but not properly maintained. GPG2 uses a better file format for private keys that GPG1 does not understand. Therefore GPG2 allows for example to merge GPG subkeys for private keys. If one relies on GPG2. Also the GPG agent for GPG2 seems to be better than the GPG1 agent. AFAIK there is no benefit for anyone to still use GPG1 over GPG2 except for not updating code now. For me it only causes problems when I accidentally use GPG1 instead of GPG2 because the gpg command points to GPG1. Also I remember that there might be issues with GPG signing GIT commits since it defaults to using the gpg command instead of using the gpg2 command. Eventually GPG1 will die anyhow. Also the default library gpgme supports GPG2 correctly and it would be better for code to use GPG via gpgme instead of writing own wrappers as an extension/library anyhow IMHO. Kind regards Till ___ 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 19:01 +0200, Igor Gnatenko wrote:
> 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
Pungi still uses yum:
[adamw@adam pungi (master)]$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
[adamw@adam pungi (master)]$ grep -R yum pungi/
pungi/arch.py:def tree_arch_to_yum_arch(tree_arch):
pungi/arch.py:yum_arch = TREE_ARCH_YUM_ARCH_MAP.get(tree_arch, tree_arch)
pungi/arch.py:return yum_arch
pungi/arch.py:def get_multilib_arch(yum_arch):
pungi/arch.py:arch_info = rpmUtils.arch.getMultiArchInfo(yum_arch)
pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
pungi/arch.py:multilib_arch = get_multilib_arch(yum_arch)
pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
pungi/arch.py:for arch in rpmUtils.arch.getArchList(yum_arch):
pungi/multilib.py:def do_multilib(yum_arch, methods, repos, tmpdir, logfile):
pungi/multilib.py:import yum
pungi/multilib.py:archlist = yum.rpmUtils.arch.getArchList(yum_arch)
pungi/multilib.py:yumbase = yum.YumBase()
pungi/multilib.py:yumbase.preconf.init_plugins = False
pungi/multilib.py:yumbase.preconf.root = tmpdir
pungi/multilib.py:# must run doConfigSetup() before touching yumbase.conf
pungi/multilib.py:yumbase.doConfigSetup(fn="/dev/null")
pungi/multilib.py:yumbase.conf.cache = False
pungi/multilib.py:yumbase.conf.cachedir = tmpdir
pungi/multilib.py:yumbase.conf.exactarch = True
pungi/multilib.py:yumbase.conf.gpgcheck = False
pungi/multilib.py:yumbase.conf.logfile = logfile
pungi/multilib.py:yumbase.conf.plugins = False
pungi/multilib.py:yumbase.conf.reposdir = []
pungi/multilib.py:yumbase.verbose_logger.setLevel(logging.ERROR)
pungi/multilib.py:yumbase.doRepoSetup()
pungi/multilib.py:yumbase.doTsSetup()
pungi/multilib.py:yumbase.doRpmDBSetup()
pungi/multilib.py:
yumbase.ts.pushVSFlags((rpm._RPMVSF_NOSIGNATURES|rpm._RPMVSF_NODIGESTS))
pungi/multilib.py:for repo in yumbase.repos.findRepos("*"):
pungi/multilib.py:yumbase.add_enable_repo(repo_id, baseurls=[baseurl])
pungi/multilib.py:yumbase.doSackSetup(archlist=archlist)
pungi/multilib.py:yumbase.doSackFilelistPopulate()
pungi/multilib.py:for po in sorted(yumbase.pkgSack):
pungi/multilib.py:help="path or url to yum repo; can be specified
multiple times",
pungi/phases/pkgset/sources/source_repos.py:# populate pkgset from yum repos
pungi/phases/osbs.py:config['yum_repourls'] = [self._get_repo(compose,
variant)]
pungi/phases/gather/methods/method_deps.py:from pungi.arch import
tree_arch_to_yum_arch
pungi/phases/gather/methods/method_deps.py:yum_arch =
tree_arch_to_yum_arch(arch)
pungi/phases/gather/methods/method_deps.py:cmd =
pungi_wrapper.get_pungi_cmd(pungi_conf, destdir=tmp_dir, name=variant.uid,
selfhosting=selfhosting, fulltree=fulltree, arch=yum_arch, full_archlist=True,
greedy=greedy_method, cache_dir=cache_dir, lookaside_repos=lookaside_repos,
multilib_methods=multilib_methods)
pungi/wrappers/comps.py:import yum.comps
pungi/wrappers/comps.py:self.comps = yum.comps.Comps()
pungi/wrappers/kojiwrapper.py:# HACK: remove rpmdb and yum cache
pungi/wrappers/kojiwrapper.py:command = "rm -f /var/lib/rpm/__db*; rm
-rf /var/cache/yum/*; set -x; " + command
pungi/checks.py:("yum-utils", "/usr/bin/createrepo", None),
pungi/checks.py:("yum-utils", "/usr/bin/mergerepo", None),
pungi/checks.py:("yum-utils", "/usr/bin/repoquery", None),
pungi/config.py:import yum
pungi/config.py:self.set('pungi', 'arch',
yum.rpmUtils.arch.getBaseArch())
pungi/gather.py:import yum
pungi/gather.py:def yumlocked(method):
pungi/gather.py:with self.yumlock:
pungi/gather.py:self.yum_arch =
arch_module.tree_arch_to_yum_arch(self.tree_arch)
pungi/gather.py:"""A call back function used with yum."""
pungi/gather.py:class PungiYum(yum.YumBase):
pungi/gather.py:yum.YumBase.__init__(self)
pungi/gather.py:yum.logging.basicConfig(level=yum.logging.DEBUG,
filename=logfile)
pungi/gather.py:# This function overrides a yum function, allowing
pungi to control
pungi/gather.py:result = yum.YumBase._compare_providers(self, *args,
**kwargs)
pungi/gather.py:filename = self.config.get('pungi', 'cachedir') +
"/yumlock"
pungi/gather.py:self.yumlock = ReentrantYumLock(lock, self.logger)
pun
Re: RFC: retiring yum
Hi, On Mon, Sep 04, 2017 at 12:22:27PM +0200, Vít Ondruch wrote: > Interesting. I already requested something like this previously [1], but > had not good enough use case for it ... May be you want to recycle my > ticket? There is now an accepted upstream ticket, the patch is still missing, though: https://github.com/rpm-software-management/libdnf/issues/170 Kind regards Till ___ 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 4 September 2017 at 17:15, Dennis Gilmore wrote: > The correct way to deal with appstream is to add the appstream data to > rpm headers and then teach createrepo to make the appropriate metadata > files. I'm sure we've had this discussion before, but: * What happens if a single package contains two desktop files? * Would we embed a 32bit color 128x128 icon in the rpm header (10kb per app)? * Would we embed all the translations in the appdata file, or just the entire appdata file (92kb per app)? * Would we include the entire .desktop file and all the translations there too? > you would then have appropriate appdata in the server, > workstation etc repos We'd have larger rpms for no end-user gain. The metadata just has to exist long enough to be collected into one large AppStream file (and included in the metadata repomd. I see no gain whatsoever for distributing the single-package appstream metadata as part of the package download or included in the rpmdb. It's just a workaround, just the same as running appstream-builder+modifyrepo on a tree of built rpms is. Richard. ___ 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 Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes wrote: > On 4 September 2017 at 17:15, Dennis Gilmore wrote: >> The correct way to deal with appstream is to add the appstream data to >> rpm headers and then teach createrepo to make the appropriate metadata >> files. > > I'm sure we've had this discussion before, but: > > * What happens if a single package contains two desktop files? > * Would we embed a 32bit color 128x128 icon in the rpm header (10kb per app)? > * Would we embed all the translations in the appdata file, or just the > entire appdata file (92kb per app)? > * Would we include the entire .desktop file and all the translations there > too? > >> you would then have appropriate appdata in the server, >> workstation etc repos > > We'd have larger rpms for no end-user gain. The metadata just has to > exist long enough to be collected into one large AppStream file (and > included in the metadata repomd. I see no gain whatsoever for > distributing the single-package appstream metadata as part of the > package download or included in the rpmdb. It's just a workaround, > just the same as running appstream-builder+modifyrepo on a tree of > built rpms is. > It sounds like it would make more sense for createrepo_c to link to the AppStream builder library to handle AppStream metadata processing as part of the createrepo_c repodata generation, wouldn't it? Then it accomplishes the same goal without bloating the rpm headers with more things that don't make sense in 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: GnuPG 2.2.0 and replacement of GnuPG1
On Mon, Sep 04, 2017 at 06:23:27PM +0200, Roberto Ragusa wrote: > On 09/04/2017 06:13 PM, Till Maas wrote: > > You need to add --batch to the command line: > > $ LANG=C date|gpg2 --batch --passphrase aaa -ca | gpg2 --batch > > --passphrase aaa > > gpg: AES encrypted data > > gpg: encrypted with 1 passphrase > > Mon Sep 4 18:12:56 CEST 2017 > > You are right, but existing scripts do not expect this, > especially if they are calling "gpg" and getting gpg2. Is there are a specific script you are wondering about? Then we can fix that. The scripts need to be changed eventually anyhow and using above command line works with gpg1 as well. Btw. on current Debian systems and RHEL/CentOS 7 systems it is already gpg2, therefore the scripts cannot expect this in general anymore anyhow. Kind regards Till ___ 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 4 September 2017 at 17:56, Neal Gompa wrote: > It sounds like it would make more sense for createrepo_c to link to > the AppStream builder library to handle AppStream metadata processing > as part of the createrepo_c repodata generation, wouldn't it? 100% agree. This does take some time currently (as we have to decompress some files from the lzma archives) but this is currently done using my AMD Athlon Neo Microserver with spinning rust drives. Using something XEONy and SSDy it'd be orders of magnitude faster. Are we sure that we're using createrepo_c for composes? I know we *used* to be the old python one for some reason. Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: CI projects in Copr
Hey, Petr On Mon, Sep 4, 2017 at 4:27 PM, Petr Stodulka wrote: > I apologize for late response as I was on holiday. Not sure if you already > talked together about that but I agree with Pavel. `make srpm` solves only > _one_ > type of troubles. I guess that usually I will get response from upstream > like that: > -- we will not add Makefile just because of COPR that is not important > for us in any way > -- we will not modify Makefile just because of... > etc. > > It would work for us where we are upstream, but it is just another mess > next to _setup.py_ > for example. Really, the possibility of own script inside copr is much > more convenient, it is > more generic solution and covers many more troubles. > > Personally from my point of view, I would rather invest (e.g.) one more > week to generic > solution than save that time for partial solution. But I don't see into > the COPR and I will > not work on it so I am not saying that it has to be done in that way. > > well, personally, I think the two solutions would be equivalent, while `make srpm` would be cleaner on API and easier to setup (the only diff would be that in the case of srpm the invocation would be always the same, otherwise there would be no diff). I might contact you for more information, but alright, if you feel the custom script is more convenient, then I am all for it. But first, I would like to make a proposal of each option (with screenshots and just complete feature request description) so that users can clearly see the options and pick what they like the best. We can work with Pavel on it. If you agree, I would post the two proposals here before actual implementation. > > > On 4.9.2017 09:47, Pavel Raiskup wrote: > > On Friday, September 1, 2017 12:16:32 PM CEST Michal Novotny wrote: > >> On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) > >>> 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. > > > > Sure, real world example [1]. There's no Makefile in the root directory > (and I > > don't even plan to propose adding it as that's java project, so 'make > srpm' is > > sort of no-go). > > > > We agreed with upstream on the (super-ugly btw.) directory structure > under > > packaging/rpm; I hope this is one day to be replaced by trivial: > > > > packaging/rpm/generate-srpm.sh > > packaging/rpm/spec.template > > > >> Well, we can continue discussion e.g. also in PRs if people are > interested > >> in this. > > > > Accepted, though I thought that we could s/make srpm/any command/ right > now to > > avoid spending additional bucks later with the PRs. Likely, once the > new build > > method is added we'll maintain it forever so the bad decision is not > completely > > free of charge. > > > > [1] https://github.com/pgjdbc/pgjdbc > > > > Pavel > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > -- > Petr Stodulka > Core Services (In-place upgrades and migrations) > IRC nicks: pstodulk, skytak > Red Hat > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
On Mon, Sep 4, 2017 at 1:20 PM, Richard Hughes wrote: > On 4 September 2017 at 17:56, Neal Gompa wrote: >> It sounds like it would make more sense for createrepo_c to link to >> the AppStream builder library to handle AppStream metadata processing >> as part of the createrepo_c repodata generation, wouldn't it? > > 100% agree. This does take some time currently (as we have to > decompress some files from the lzma archives) but this is currently > done using my AMD Athlon Neo Microserver with spinning rust drives. > Using something XEONy and SSDy it'd be orders of magnitude faster. Are > we sure that we're using createrepo_c for composes? I know we *used* > to be the old python one for some reason. > We have been for the last few releases, I believe. -- 真実はいつも一つ！/ 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, Sep 4, 2017 at 11:41 AM Adam Williamson wrote: > On Sun, 2017-09-03 at 16:13 +0100, Sérgio Basto wrote: > > On Sat, 2017-09-02 at 14:10 -0500, Michael Cronenworth wrote: > > > On Sep 2, 2017 11:36 AM, Adam Williamson > > > wrote: > > > So I'm gonna start working on the 6.9.9 downgrade in F27, and I'm > > > tempted to just downgrade Rawhide at the same time, and if we > > > actually > > > do decide to try 7 again, we can start over at that time. Do you > > > agree > > > with that plan? Thanks! (It doesn't change anything about the > > > required > > > epoch bumps, because even if we did 6.9.9 in F27 and stayed with 7 > > > in > > > Rawhide, we'd need to bump the epoch on *both* to ensure Rawhide's 7 > > > was ahead of F27's 6). > > > > > > Based on the response from ImageMagick let's rebuild for version 6 in > > > F27+. We should keep 7, but as ImageMagick7 instead. > > > > Well if we go to have ImageMagick6 and ImageMagick7 in F27+ and since > > ImageMagick7 should be the main package, in my point of view , we > > should add ImageMagick6 package and maintain ImageMagick as is , like, > > for example, openssl-1.1 and compat-openssl10 . > > Nope, that's exactly the opposite of what FESCo agreed: IM7 can only go > in as the *variant* package, not the main one. The main one must be > IM6. We didn't specifically rule on the naming, FWIW. As far as IM7 being the variant package, we mostly ruled that for F27, nothing using IM in the release blocking media may require IM7. I'm personally neutral on how the files and packages are named as long as the implementation accomplishes that goal. For F28, FESCo will consider any proposal brought to us as a Change Proposal (complete with a plan for rebuilds and migrations). > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > 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: Urgent attention required; ImageMagick update breakage
On Mon, 2017-09-04 at 17:55 +, Stephen Gallagher wrote: > > We didn't specifically rule on the naming, FWIW. As far as IM7 being the > variant package, we mostly ruled that for F27, nothing using IM in the > release blocking media may require IM7. I'm personally neutral on how the > files and packages are named as long as the implementation accomplishes > that goal. well, okay, fine, I guess *technically* we could make ImageMagick be 7 and have ImageMagick6 and change the requirements in every single package that currently requires ImageMagick. But...let's not do that? :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GnuPG 2.2.0 and replacement of GnuPG1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2017-09-04 at 18:15 +0200, Till Maas wrote: > On Sun, Sep 03, 2017 at 01:45:40PM +0200, Igor Gnatenko wrote: > > GnuPG 2.2.0 has --enable-gpg-is-gpg2 which would install compat > > symlink > > from /usr/bin/gpg to /usr/bin/gpg2.. > > > > Is it time to retire gnupg (v1) ? > > It would be great if we could make gpg2 as the default (add symlink > from > /usr/bin/gpg to /usr/bin/gpg2) and move gpg1 to /usr/bin/gpg1. Debian > beat us to this. I was also thinking about proposing this as a new > Systemwide Change. Would you be willing to co-own this feature with > me? Sure! Let's talk over IRC one day and agree on further steps 😉 > > Kind regards > Till > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmtnREACgkQaVcUvRu8 X0xnNg/+KHZn17qIUByj7IJ32llVH/97CdTpp96MNy4UjtBAUuCBoh3sl1m9THZj ZEUNjRV0H3FpgG65DAQf4cUGJLU1S/o1iGeczaiv1vsd1EC7MHwbo3LSnddSeXPh etXzJqwpAR9vCGfICf0/3UnUmep1BJrNlztPWp8v3m4WWwE+/XoCbRRwugTCxxmy NhUV+EHa2TVRCwtWqDwm7bOfh4KiK3XOZiktryUFnySOTBku4i2damU6jpdKiaME 2t5093Os66RtqFTAEh+XaK5gyuTjaQ27qUomMDHj87YFxx6e1jJ7+vJ3nEPxvFqs YNlnSTor7H75IdeXquUwkbViJ90RVi0r9LSS6hmk/THRmWnDvcvDnXgT8+b1RnTd h0rMaaXG/dMtwbdf4QCKZekbT6emzZyCt8HyzkkIkG0KqOwWlT84atOFpazsb7VD ownPplLaeDuCkjwkjaamXfFkrBDuO+C5LVFQ01J0fLdCvzikXHskxlX+JtLLZByg lhGZNBrYhWmyhQIp9o9lEmQRsVdHeOLRke7vMDVHVryD0XgRpb3jAFsvIbJ65RoA SoAT9XHGYEynfLNFizhBMdFWcHfX6b8yNFV7VbODfUHe2TnieMc1oBYLwqEqF1CI IBtChqxsUR8/DjdglFGkjJLNZqnLWpfqb1atvlGym6ImR0FpKg0= =CkjG -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 Mon, 2017-09-04 at 09:25 -0700, Adam Williamson wrote:
> On Fri, 2017-09-01 at 19:01 +0200, Igor Gnatenko wrote:
> > 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
>
> Pungi still uses yum:
Definitely it does!
>
> [adamw@adam pungi (master)]$ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
>
> nothing to commit, working tree clean
> [adamw@adam pungi (master)]$ grep -R yum pungi/
> pungi/arch.py:def tree_arch_to_yum_arch(tree_arch):
> pungi/arch.py:yum_arch = TREE_ARCH_YUM_ARCH_MAP.get(tree_arch,
> tree_arch)
> pungi/arch.py:return yum_arch
> pungi/arch.py:def get_multilib_arch(yum_arch):
> pungi/arch.py:arch_info =
> rpmUtils.arch.getMultiArchInfo(yum_arch)
> pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
> pungi/arch.py:multilib_arch = get_multilib_arch(yum_arch)
> pungi/arch.py:yum_arch = tree_arch_to_yum_arch(tree_arch)
> pungi/arch.py:for arch in rpmUtils.arch.getArchList(yum_arch):
> pungi/multilib.py:def do_multilib(yum_arch, methods, repos, tmpdir,
> logfile):
> pungi/multilib.py:import yum
> pungi/multilib.py:archlist =
> yum.rpmUtils.arch.getArchList(yum_arch)
> pungi/multilib.py:yumbase = yum.YumBase()
> pungi/multilib.py:yumbase.preconf.init_plugins = False
> pungi/multilib.py:yumbase.preconf.root = tmpdir
> pungi/multilib.py:# must run doConfigSetup() before touching
> yumbase.conf
> pungi/multilib.py:yumbase.doConfigSetup(fn="/dev/null")
> pungi/multilib.py:yumbase.conf.cache = False
> pungi/multilib.py:yumbase.conf.cachedir = tmpdir
> pungi/multilib.py:yumbase.conf.exactarch = True
> pungi/multilib.py:yumbase.conf.gpgcheck = False
> pungi/multilib.py:yumbase.conf.logfile = logfile
> pungi/multilib.py:yumbase.conf.plugins = False
> pungi/multilib.py:yumbase.conf.reposdir = []
> pungi/multilib.py:yumbase.verbose_logger.setLevel(logging.ERROR)
> pungi/multilib.py:yumbase.doRepoSetup()
> pungi/multilib.py:yumbase.doTsSetup()
> pungi/multilib.py:yumbase.doRpmDBSetup()
> pungi/multilib.py:yumbase.ts.pushVSFlags((rpm._RPMVSF_NOSIGNATURE
> S|rpm._RPMVSF_NODIGESTS))
> pungi/multilib.py:for repo in yumbase.repos.findRepos("*"):
> pungi/multilib.py:yumbase.add_enable_repo(repo_id,
> baseurls=[baseurl])
> pungi/multilib.py:yumbase.doSackSetup(archlist=archlist)
> pungi/multilib.py:yumbase.doSackFilelistPopulate()
> pungi/multilib.py:for po in sorted(yumbase.pkgSack):
> pungi/multilib.py:help="path or url to yum repo; can be
> specified multiple times",
> pungi/phases/pkgset/sources/source_repos.py:# populate pkgset
> from yum repos
> pungi/phases/osbs.py:config['yum_repourls'] =
> [self._get_repo(compose, variant)]
> pungi/phases/gather/methods/method_deps.py:from pungi.arch import
> tree_arch_to_yum_arch
> pungi/phases/gather/methods/method_deps.py:yum_arch =
> tree_arch_to_yum_arch(arch)
> pungi/phases/gather/methods/method_deps.py:cmd =
> pungi_wrapper.get_pungi_cmd(pungi_conf, destdir=tmp_dir,
> name=variant.uid, selfhosting=selfhosting, fulltree=fulltree,
> arch=yum_arch, full_archlist=True, greedy=greedy_method,
> cache_dir=cache_dir, lookaside_repos=lookaside_repos,
> multilib_methods=multilib_methods)
> pungi/wrappers/comps.py:import yum.comps
> pungi/wrappers/comps.py:self.comps = yum.comps.Comps()
> pungi/wrappers/kojiwrapper.py:# HACK: remove rpmdb and yum
> cache
> pungi/wrappers/kojiwrapper.py:command = "rm -f
> /var/lib/rpm/__db*; rm -rf /var/cache/yum/*; set -x; " + command
> pungi/checks.py:("yum-utils", "/usr/bin/createrepo", None),
> pungi/checks.py:("yum-utils", "/usr/bin/mergerepo", None),
> pungi/checks.py:("yum-utils", "/usr/bin/repoquery", None),
> pungi/config.py:import yum
> pungi/config.py:self.set('pungi', 'arch',
> yum.rpmUtils.arch.getBaseArch())
> pungi/gather.py:import yum
> pungi/gather.py:def yumlocked(method):
> pungi/gather.py:with self.yumlock:
> pungi/gather.py:self.yum_arch =
> arch_module.tree_arch_to_yum_arch(self.tree_arch)
> pungi/gather.py:"""A call back function used with yum."""
> pungi/gather.py:class PungiYum(yum.YumBase):
> pungi/gather.py:yum.YumBase.__init__(self)
> pungi/gather.py:yum.logging.basicConfig(level=yum.logging.DEB
> UG, filename=logfile)
>
Re: RFC: retiring yum
On Mon, 2017-09-04 at 20:37 +0200, Igor Gnatenko wrote: > > Some of those are false positives (just names for things that are > > actually moved to dnf), but a lot of them are actual usage of the yum > > module. > > Pungi in rawhide uses DNF backend for gathering, so irrelevant.. 😉 I don't believe all those uses are on the gathering path. Have you double checked this? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net 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 Mon, 2017-09-04 at 11:54 -0700, Adam Williamson wrote: > On Mon, 2017-09-04 at 20:37 +0200, Igor Gnatenko wrote: > > > Some of those are false positives (just names for things that are > > > actually moved to dnf), but a lot of them are actual usage of the yum > > > module. > > > > Pungi in rawhide uses DNF backend for gathering, so irrelevant.. 😉 > > I don't believe all those uses are on the gathering path. Have you > double checked this? https://pagure.io/pungi/issue/722 is an example of a Pungi codepath I believe is running through the yum module even in current F27 / Rawhide. I'm willing to be wrong, but...please do check it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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-09-04 at 11:01 -0700, Adam Williamson wrote: > On Mon, 2017-09-04 at 17:55 +, Stephen Gallagher wrote: > > > > We didn't specifically rule on the naming, FWIW. As far as IM7 > > being the > > variant package, we mostly ruled that for F27, nothing using IM in > > the > > release blocking media may require IM7. I'm personally neutral on > > how the > > files and packages are named as long as the implementation > > accomplishes > > that goal. > > well, okay, fine, I guess *technically* we could make ImageMagick be > 7 > and have ImageMagick6 and change the requirements in every single > package that currently requires ImageMagick. That is the point, how many package fail to build with ImageMagick7 ? we "just" need change requires on FTBFS packages (with ImageMagick7) > But...let's not do that? > :) -- Sérgio M. B. ___ 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
El lun, 04-09-2017 a las 17:33 +0100, Richard Hughes escribió: > On 4 September 2017 at 17:15, Dennis Gilmore wrote: > > The correct way to deal with appstream is to add the appstream data > > to > > rpm headers and then teach createrepo to make the appropriate > > metadata > > files. > > I'm sure we've had this discussion before, but: We have had this discussion about 3 or 4 times. > * What happens if a single package contains two desktop files? both end up in the headers, > * Would we embed a 32bit color 128x128 icon in the rpm header (10kb > per app)? we would have to, there is simply no sane way to extract and manage things from inside the rpms. the appdata being agnostic is great, but there has to be a technology specific way to manage the data without expensive overhead > * Would we embed all the translations in the appdata file, or just > the > entire appdata file (92kb per app)? > * Would we include the entire .desktop file and all the translations > there too? > > > you would then have appropriate appdata in the server, > > workstation etc repos > > We'd have larger rpms for no end-user gain. The metadata just has to > exist long enough to be collected into one large AppStream file (and > included in the metadata repomd. I see no gain whatsoever for > distributing the single-package appstream metadata as part of the > package download or included in the rpmdb. It's just a workaround, > just the same as running appstream-builder+modifyrepo on a tree of > built rpms is. we would have a end user gain, they would get consistent updated correct data all the time. Dennis ___ 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
El lun, 04-09-2017 a las 12:56 -0400, Neal Gompa escribió: > On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes > wrote: > > On 4 September 2017 at 17:15, Dennis Gilmore > > wrote: > > > The correct way to deal with appstream is to add the appstream > > > data to > > > rpm headers and then teach createrepo to make the appropriate > > > metadata > > > files. > > > > I'm sure we've had this discussion before, but: > > > > * What happens if a single package contains two desktop files? > > * Would we embed a 32bit color 128x128 icon in the rpm header (10kb > > per app)? > > * Would we embed all the translations in the appdata file, or just > > the > > entire appdata file (92kb per app)? > > * Would we include the entire .desktop file and all the > > translations there too? > > > > > you would then have appropriate appdata in the server, > > > workstation etc repos > > > > We'd have larger rpms for no end-user gain. The metadata just has > > to > > exist long enough to be collected into one large AppStream file > > (and > > included in the metadata repomd. I see no gain whatsoever for > > distributing the single-package appstream metadata as part of the > > package download or included in the rpmdb. It's just a workaround, > > just the same as running appstream-builder+modifyrepo on a tree of > > built rpms is. > > > > It sounds like it would make more sense for createrepo_c to link to > the AppStream builder library to handle AppStream metadata processing > as part of the createrepo_c repodata generation, wouldn't it? Then it > accomplishes the same goal without bloating the rpm headers with more > things that don't make sense in there. It would not be a good way to do things, the expensive bit is extacting and manageing the appdata info. that is super expensive and comes with other costs. we currently use createrepo_c for GA releases and the old createrepo for updates. There has to be a way to easily extract the data without having to reach into the belly of the rpm payload. The soultion we use needs to work for anyone making repos and not be tied in anyway to a specific implementation of how we build ship and manage the software lifecycle. Dennis ___ 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 Mon, Sep 4, 2017 at 3:57 PM, Dennis Gilmore wrote: > El lun, 04-09-2017 a las 17:33 +0100, Richard Hughes escribió: >> On 4 September 2017 at 17:15, Dennis Gilmore wrote: >> > The correct way to deal with appstream is to add the appstream data >> > to >> > rpm headers and then teach createrepo to make the appropriate >> > metadata >> > files. >> >> I'm sure we've had this discussion before, but: > We have had this discussion about 3 or 4 times. > >> * What happens if a single package contains two desktop files? > both end up in the headers, >> * Would we embed a 32bit color 128x128 icon in the rpm header (10kb >> per app)? > we would have to, there is simply no sane way to extract and manage > things from inside the rpms. the appdata being agnostic is great, but > there has to be a technology specific way to manage the data without > expensive overhead > >> * Would we embed all the translations in the appdata file, or just >> the >> entire appdata file (92kb per app)? >> * Would we include the entire .desktop file and all the translations >> there too? >> >> > you would then have appropriate appdata in the server, >> > workstation etc repos >> >> We'd have larger rpms for no end-user gain. The metadata just has to >> exist long enough to be collected into one large AppStream file (and >> included in the metadata repomd. I see no gain whatsoever for >> distributing the single-package appstream metadata as part of the >> package download or included in the rpmdb. It's just a workaround, >> just the same as running appstream-builder+modifyrepo on a tree of >> built rpms is. > > we would have a end user gain, they would get consistent updated > correct data all the time. > We could do that *now*. Other distributions (openSUSE, Mageia, Debian, etc.) generate the metadata and append it to the repodata, so that it *is* consistent since it was made along with the regular metadata. It would probably be somewhat faster with createrepo_c itself supporting it, but it's not mandatory. -- 真実はいつも一つ！/ 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 Mon, Sep 4, 2017 at 4:02 PM, Dennis Gilmore wrote: > El lun, 04-09-2017 a las 12:56 -0400, Neal Gompa escribió: >> On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes >> wrote: >> > On 4 September 2017 at 17:15, Dennis Gilmore >> > wrote: >> > > The correct way to deal with appstream is to add the appstream >> > > data to >> > > rpm headers and then teach createrepo to make the appropriate >> > > metadata >> > > files. >> > >> > I'm sure we've had this discussion before, but: >> > >> > * What happens if a single package contains two desktop files? >> > * Would we embed a 32bit color 128x128 icon in the rpm header (10kb >> > per app)? >> > * Would we embed all the translations in the appdata file, or just >> > the >> > entire appdata file (92kb per app)? >> > * Would we include the entire .desktop file and all the >> > translations there too? >> > >> > > you would then have appropriate appdata in the server, >> > > workstation etc repos >> > >> > We'd have larger rpms for no end-user gain. The metadata just has >> > to >> > exist long enough to be collected into one large AppStream file >> > (and >> > included in the metadata repomd. I see no gain whatsoever for >> > distributing the single-package appstream metadata as part of the >> > package download or included in the rpmdb. It's just a workaround, >> > just the same as running appstream-builder+modifyrepo on a tree of >> > built rpms is. >> > >> >> It sounds like it would make more sense for createrepo_c to link to >> the AppStream builder library to handle AppStream metadata processing >> as part of the createrepo_c repodata generation, wouldn't it? Then it >> accomplishes the same goal without bloating the rpm headers with more >> things that don't make sense in there. > It would not be a good way to do things, the expensive bit is extacting > and manageing the appdata info. that is super expensive and comes with > other costs. we currently use createrepo_c for GA releases and the old > createrepo for updates. There has to be a way to easily extract the > data without having to reach into the belly of the rpm payload. The > soultion we use needs to work for anyone making repos and not be tied > in anyway to a specific implementation of how we build ship and manage > the software lifecycle. > Wait, what? Is this because of mash? That should go away with Bodhi moving to pungi, right? As for avoiding the rpm payload, I don't think you're going to find a workable solution. Pretty much all distributions supporting AppStream metadata are doing it this way. The appstream-generator tool (used by the Debian and Arch guys) peeks into deb/archpkg files and grabs the data out too. Richard's appstream-builder follows the same strategy. The only possible approach you might find palatable is SUSE's... SUSE's method of dealing with AppStream data is to have a brp script (brp-extract-appdata) that extracts the information during package build time. The build service then processes that extracted metadata and creates the correct appstream repodata and appends it to the rpm-md repodata. That could work for us, but it'd require work to dist-repos and pungi and bodhi so that the extracted appstream content is merged together to create the repodata and properly appended. SUSE's approach also works rather well because the OBS is aware of the distribution dependencies and automatically handles ensuring the consistency is there. It's pretty much Koji + Koschei + COPR+ releng mass rebuild scripts + pungi + bodhi in one system. No split brains means consistency is easy to guarantee. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity WG (once every two weeks)
Dear all, You are kindly invited to the meeting: Modularity WG (once every two weeks) on 2017-09-05 from 10:00:00 to 11:00:00 US/Eastern At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) The agenda for the meeting is available at [modularity-wg-agendas pad](https://board.net/p/modularity-wg-agendas). Source: https://apps.fedoraproject.org/calendar/meeting/5249/ ___ 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-09-04 at 20:07 +0100, Sérgio Basto wrote: > On Mon, 2017-09-04 at 11:01 -0700, Adam Williamson wrote: > > On Mon, 2017-09-04 at 17:55 +, Stephen Gallagher wrote: > > > > > > We didn't specifically rule on the naming, FWIW. As far as IM7 > > > being the > > > variant package, we mostly ruled that for F27, nothing using IM > > > in > > > the > > > release blocking media may require IM7. I'm personally neutral on > > > how the > > > files and packages are named as long as the implementation > > > accomplishes > > > that goal. > > > > well, okay, fine, I guess *technically* we could make ImageMagick > > be > > 7 > > and have ImageMagick6 and change the requirements in every single > > package that currently requires ImageMagick. > > That is the point, how many package fail to build with ImageMagick7 > ? > we "just" need change requires on FTBFS packages (with ImageMagick7) We already have ImageMagick 6.9.3 ABI compatibility package. https://bodhi.fedoraproject.org/updates/FEDORA-2017-20d59de2dc > > But...let's not do that? > > :) > > > -- > Sérgio M. B. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Sérgio M. B. ___ 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-09-04 at 20:07 +0100, Sérgio Basto wrote: > > That is the point, how many package fail to build with ImageMagick7 ? > we "just" need change requires on FTBFS packages (with ImageMagick7) No it isn't the point. More things actually use the ImageMagick *CLI* than use the library, and the CLI of ImageMagick 7 is very different from the CLI of ImageMagick 6. This is the *main* reason we do not just want to make the ImageMagick package suddenly become ImageMagick 7 - because IM 7 does not provide the CLI people currently expect from the package called 'ImageMagick'. It's not primarily about things which build against the libraries. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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-09-04 at 23:15 +0100, Sérgio Basto wrote: > > We already have ImageMagick 6.9.3 ABI compatibility package. > > https://bodhi.fedoraproject.org/updates/FEDORA-2017-20d59de2dc I don't really see *why*. It doesn't seem to be very necessary. We've already rebuilt everything in 25 and 26 for 6.9.9.9. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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-09-04 at 16:11 -0700, Adam Williamson wrote: > On Mon, 2017-09-04 at 20:07 +0100, Sérgio Basto wrote: > > > > That is the point, how many package fail to build with ImageMagick7 > > ? > > we "just" need change requires on FTBFS packages (with > > ImageMagick7) > > No it isn't the point. More things actually use the ImageMagick *CLI* > than use the library, and the CLI of ImageMagick 7 is very different > from the CLI of ImageMagick 6. This is the *main* reason we do not > just > want to make the ImageMagick package suddenly become ImageMagick 7 - > because IM 7 does not provide the CLI people currently expect from > the > package called 'ImageMagick'. It's not primarily about things which > build against the libraries. OK, I understood your point of view and I change my opinion to youropinion . Best regards, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Better to bundle a library or package different version than upstream?
Dear all, About ten days ago I asked a question on this list, but I guess on one hand it was too specific, while on the other it coincided with people travelling to Flock or being on vacation. As I really want to get the package in question back in Fedora, I will ask again and I will try to be more abstract and concise. For anyone interested, there is a link to the original post at the end of this message. Package foo, which depends on library bar for importing a certain type of files, was retired a couple of releases ago. The library is still in Fedora, in two different versions, with different functionality (bar2-2.0.0 & bar-oldsnapshot), but no other package depends on it. Since the retirement, both foo and bar saw active development with both projects sharing a few contributors; foo has had a number of public releases whereas bar hasn't had any, but there is an unreleased newer version (bar-3.0.0) in its VCS. Up to a specific release, the bar version bundled with foo was identical with upstream bar; that is no longer the case, as the bundled library is closer to that of the final public release, while the upstream version has been tweaked to work with a third program, which is also included in Fedora, but does not make use of the bar library. The upstream bar version won't work with foo for the moment. I have spoken with the upstream developers and I was told that both branches will merge back before the bar-3.0.0 public release. So what I am asking is this: Is it OK if I (re)introduce two packages, foo and bar3, obsoleting bar and bar2 at the same time, but using foo's source for bar or should I opt to keep bar bundled with foo, until the two different forks are reunited? Best regards Alex https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EMVB3JGM5AZVVO7NA3E7DHJLB32CMJJW/ ___ 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
Dne 4.9.2017 v 22:02 Dennis Gilmore napsal(a): > El lun, 04-09-2017 a las 12:56 -0400, Neal Gompa escribió: >> On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes >> wrote: >>> On 4 September 2017 at 17:15, Dennis Gilmore >>> wrote: The correct way to deal with appstream is to add the appstream data to rpm headers and then teach createrepo to make the appropriate metadata files. >>> I'm sure we've had this discussion before, but: >>> >>> * What happens if a single package contains two desktop files? >>> * Would we embed a 32bit color 128x128 icon in the rpm header (10kb >>> per app)? >>> * Would we embed all the translations in the appdata file, or just >>> the >>> entire appdata file (92kb per app)? >>> * Would we include the entire .desktop file and all the >>> translations there too? >>> you would then have appropriate appdata in the server, workstation etc repos >>> We'd have larger rpms for no end-user gain. The metadata just has >>> to >>> exist long enough to be collected into one large AppStream file >>> (and >>> included in the metadata repomd. I see no gain whatsoever for >>> distributing the single-package appstream metadata as part of the >>> package download or included in the rpmdb. It's just a workaround, >>> just the same as running appstream-builder+modifyrepo on a tree of >>> built rpms is. >>> >> It sounds like it would make more sense for createrepo_c to link to >> the AppStream builder library to handle AppStream metadata processing >> as part of the createrepo_c repodata generation, wouldn't it? Then it >> accomplishes the same goal without bloating the rpm headers with more >> things that don't make sense in there. > It would not be a good way to do things, the expensive bit is extacting > and manageing the appdata info. that is super expensive and comes with > other costs. Could you elaborate what is super expensive on this? All the rpms which contains appstream data have metainfo() virtual provides, so they can be easily discovered. Later this is just about extracting the appropriate files from that RPMs. It doesn't look that super expensive V. ___ 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
2017-09-04 19:20 GMT+02:00 Richard Hughes : > On 4 September 2017 at 17:56, Neal Gompa wrote: >> It sounds like it would make more sense for createrepo_c to link to >> the AppStream builder library to handle AppStream metadata processing >> as part of the createrepo_c repodata generation, wouldn't it? > > 100% agree. This does take some time currently (as we have to > decompress some files from the lzma archives) but this is currently > done using my AMD Athlon Neo Microserver with spinning rust drives. > Using something XEONy and SSDy it'd be orders of magnitude faster. Are > we sure that we're using createrepo_c for composes? I know we *used* > to be the old python one for some reason. As I understand, the problem with the decompression is that it fetches the payload. And if a rpm weight 100MB, it will downloads (RPMs are often stored on nfs, so network is involved) and decompress the whole 100MB (including the header, although this last might be uncompressed). On the opposite, storing information on the RPM header means grabbing only the first KB out of the whole RPM. As one can see, this might work for few RPMs, but this doesn't scale at all on a big whole repository with many arches, specially if the work from a previous appdata-builder run cannot be cached for a later updates. So I wonder if it would be possible to have a "second payload" with only the appdata (xml, imgs) that it would be possible to fetch along the header without having to get the rest of the RPM ? On the second tough, with the effort needed to extract this information out of the rpm, is it really worth to store them there in the first step ? Over storing an URL (for xml and/or imgs) in the RPM header ? Thx for correcting me where I'm wrong. -- - Nicolas (kwizart) ___ 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
Dne 5.9.2017 v 08:31 Nicolas Chauvet napsal(a): > 2017-09-04 19:20 GMT+02:00 Richard Hughes : >> On 4 September 2017 at 17:56, Neal Gompa wrote: >>> It sounds like it would make more sense for createrepo_c to link to >>> the AppStream builder library to handle AppStream metadata processing >>> as part of the createrepo_c repodata generation, wouldn't it? >> 100% agree. This does take some time currently (as we have to >> decompress some files from the lzma archives) but this is currently >> done using my AMD Athlon Neo Microserver with spinning rust drives. >> Using something XEONy and SSDy it'd be orders of magnitude faster. Are >> we sure that we're using createrepo_c for composes? I know we *used* >> to be the old python one for some reason. > As I understand, the problem with the decompression is that it fetches > the payload. > And if a rpm weight 100MB, it will downloads (RPMs are often stored on > nfs, so network is involved) and decompress the whole 100MB (including > the header, although this last might be uncompressed). > On the opposite, storing information on the RPM header means grabbing > only the first KB out of the whole RPM. > > As one can see, this might work for few RPMs, but this doesn't scale > at all on a big whole repository with many arches, specially if the > work from a previous appdata-builder run cannot be cached for a later > updates. > > So I wonder if it would be possible to have a "second payload" with > only the appdata (xml, imgs) that it would be possible to fetch along > the header without having to get the rest of the RPM ? > On the second tough, with the effort needed to extract this > information out of the rpm, is it really worth to store them there in > the first step ? Over storing an URL (for xml and/or imgs) in the RPM > header ? > > Thx for correcting me where I'm wrong. > Just another idea reading this ... could we move the AppStream data into subpackage? Vít ___ 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 Tue, 2017-09-05 at 08:31 +0200, Nicolas Chauvet wrote: > 2017-09-04 19:20 GMT+02:00 Richard Hughes : > > On 4 September 2017 at 17:56, Neal Gompa > > wrote: > > > It sounds like it would make more sense for createrepo_c to link > > > to > > > the AppStream builder library to handle AppStream metadata > > > processing > > > as part of the createrepo_c repodata generation, wouldn't it? > > > > 100% agree. This does take some time currently (as we have to > > decompress some files from the lzma archives) but this is currently > > done using my AMD Athlon Neo Microserver with spinning rust drives. > > Using something XEONy and SSDy it'd be orders of magnitude faster. > > Are > > we sure that we're using createrepo_c for composes? I know we > > *used* > > to be the old python one for some reason. > > As I understand, the problem with the decompression is that it > fetches > the payload. > And if a rpm weight 100MB, it will downloads (RPMs are often stored > on > nfs, so network is involved) and decompress the whole 100MB > (including > the header, although this last might be uncompressed). > On the opposite, storing information on the RPM header means grabbing > only the first KB out of the whole RPM. It is in Provides, so it is in primary.xml of repodata. So it should be very trivial to filter such RPMs and download only required ones. > > As one can see, this might work for few RPMs, but this doesn't scale > at all on a big whole repository with many arches, specially if the > work from a previous appdata-builder run cannot be cached for a later > updates. > > So I wonder if it would be possible to have a "second payload" with > only the appdata (xml, imgs) that it would be possible to fetch along > the header without having to get the rest of the RPM ? > On the second tough, with the effort needed to extract this > information out of the rpm, is it really worth to store them there in > the first step ? Over storing an URL (for xml and/or imgs) in the RPM > header ? That's probably something what openSUSE does, but I didn't really check so better to ask Neal.. > > Thx for correcting me where I'm wrong. > > -- > - > > Nicolas (kwizart) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmuRzAACgkQaVcUvRu8 X0zKyg//XnDPz5u1RC6jADUgnh2iZynRCWMKUuUmUvqk4a+6JQE5VkaomXpMs06H Swn7F1OY2rGp52UYDbKy92vitfytH6T/SMIgGkqb0A0EOIYlMwDi4BTdUnq0LNkb sm6lP0GNB4FFcChbKgY68frmBAxwZMwJlHthVkRBtjlMM1jKf/1WhK88gxEar7Lm +a6b8X7mOXaFIFf5zAeik6g3XwAcrp0REGaG/m9is8sV/F7gea6vDI9MRFT4G1dz dfGQxT8eYjBP8ldfWF21/7bUDjmLw6qAGvj8ni7mBHOwAXUfNv/dUDcCaJo19g3p GtDdqBOKjN8BH1Rd/7E/aApfqR8AW9qphqDPd9Dz3gJVnZJegxQkHwsTdI45H5Ij Hk8TmZL6qp5egNHWBKhOWy6CmbDB9ebPFDmJeJVe4m09rWQf7EmGyc1jL2XysXKF gKSVsRA54E6iIDneN7KSqhB90lNMifPN4OsCLORbZANBGUggcYOaAwZKg3to/AiM r0G2zLGN8n/oqFCxTvIfjZbPUEZr70vvK5L5zHxwl1W5cQzMyfJep8J6YbZtMuIs jz9YhRdxG9kqInc2YT6lNoIhrp6NvhSbhd+nhQQCMo+LYKBrAIQ8bIKzrj00f92G iRmoI9QnzdhXzvQQyz3v5WACcE1d5U4UuQnsFMWohrBjtWSrJVo= =17U1 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
