Re: Failed to push updates to stable
On Sun, 2017-04-30 at 09:24 +0800, Kalpa Welivitigoda wrote: > Hi, > > I was trying to push an update to stable and received a mail with this > notification [1], anyone experienced a similar response recently, > seems the version comparison fails. Also wonder why fc24 update is > being tried to push to fc25. > > [1] > https://taskotron.fedoraproject.org/artifacts/all/3e2dfd96-2d3f-11e7-9745-5254008e42f6/task_output/sugar-speak-52-1.fc24.log That doesn't fail anything. But what it's telling you is that the package version in F24 is now higher than the package version in F25, which is bad. You should have pushed the equivalent update to F25 earlier or at the same time. -- 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
Failed to push updates to stable
Hi, I was trying to push an update to stable and received a mail with this notification [1], anyone experienced a similar response recently, seems the version comparison fails. Also wonder why fc24 update is being tried to push to fc25. [1] https://taskotron.fedoraproject.org/artifacts/all/3e2dfd96-2d3f-11e7-9745-5254008e42f6/task_output/sugar-speak-52-1.fc24.log -- Best Regards, Kalpa Welivitigoda +65 82265081 http://about.me/callkalpa ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Orphaned Packages in branched (2017-04-30)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package(co)maintainers Status Change === abakus orphan, cicku 4 weeks ago clucene09 orphan, group::kde-sig,5 weeks ago rdieter, robert elfinfoorphan, pnemade9 weeks ago esteidcertsorphan, mihkel, rdieter0 weeks ago estonianidcard orphan, mihkel 0 weeks ago firefox-esteid-plugin orphan, mihkel 0 weeks ago firefox-esteidpkcs11loader orphan, mihkel 0 weeks ago glyphtracerorphan, pnemade9 weeks ago golang-launchpad-go-xdg-v0 orphan, agoode 8 weeks ago greadelf orphan, pnemade9 weeks ago libdigidoc orphan, anttix, kalev, 0 weeks ago mihkel, rdieter, sander85, tuju libdigidocpp orphan, anttix, kalev, 0 weeks ago mihkel, rdieter, sander85, tuju lightdm-kdeorphan, carandraug,3 weeks ago cwickert, rdieter mkdst orphan, enslaver, ryan52, 6 weeks ago wtogami python-cement orphan, derks 8 weeks ago python-compositor orphan, fonts-sig, i18n- 9 weeks ago team, pnemade python-pytgorphan, sagitter 6 weeks ago python-robofab orphan, fonts-sig, i18n- 9 weeks ago team, jpokorny, pnemade python-ufo2fdk orphan, fonts-sig, i18n- 9 weeks ago team, pnemade qdigidoc orphan, anttix, kalev, 0 weeks ago mihkel, rdieter, sander85, tuju qesteidutilorphan, anttix, kalev, 0 weeks ago mihkel, rdieter, sander85, tuju qyoto orphan, elsupergomez, group8 weeks ago ::kde-sig, jreznik, rdieter, than rmanageorphan, ashokdas, pnemade 9 weeks ago rubygem-fast_xsorphan 2 weeks ago rubygem-foreman_apiorphan 2 weeks ago rubygem-github-linguistorphan 7 weeks ago rubygem-hoptoad_notifier orphan 2 weeks ago rubygem-mobileesp_convertedorphan 2 weeks ago rubygem-robotexorphan 2 weeks ago rubygem-ruby-rc4 orphan 2 weeks ago rubygem-single_testorphan 2 weeks ago rubygem-ttfunk orphan, jstribny 2 weeks ago rubygem-xmlhashorphan 2 weeks ago telegram-cli orphan, sagitter 6 weeks ago trac-condfieldsgenshi-plugin orphan, adamwill 7 weeks ago trac-defaultcc-plugin orphan, adamwill, kevin7 weeks ago vdr-sudoku orphan 7 weeks ago yumdaemon orphan, timlau 5 weeks ago zanata-api orphan, dchen, pahuang,7 weeks ago
Orphaned Packages in rawhide (2017-04-30)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package(co)maintainers Status Change === abakus orphan, cicku 4 weeks ago clucene09 orphan, group::kde-sig,5 weeks ago rdieter, robert esteidcertsorphan, mihkel, rdieter0 weeks ago estonianidcard orphan, mihkel 0 weeks ago firefox-esteid-plugin orphan, mihkel 0 weeks ago firefox-esteidpkcs11loader orphan, mihkel 0 weeks ago glyphtracerorphan, pnemade9 weeks ago golang-launchpad-go-xdg-v0 orphan, agoode 8 weeks ago libdigidoc orphan, anttix, kalev, 0 weeks ago mihkel, rdieter, sander85, tuju libdigidocpp orphan, anttix, kalev, 0 weeks ago mihkel, rdieter, sander85, tuju lightdm-kdeorphan, carandraug,3 weeks ago cwickert, rdieter mkdst orphan, enslaver, ryan52, 6 weeks ago wtogami php-pear-Auth orphan, remi 3 weeks ago php-pear-Auth-RADIUS orphan, remi 3 weeks ago php-pear-Cache orphan, remi 3 weeks ago php-pear-Crypt-CHAPorphan, remi 3 weeks ago php-pear-DB-DataObject orphan, remi 3 weeks ago php-pear-File orphan, remi 3 weeks ago php-pear-File-CSV orphan, remi 3 weeks ago php-pear-File-Passwd orphan, remi 3 weeks ago php-pear-File-SMBPasswdorphan, remi 3 weeks ago php-pear-File-Util orphan, remi 3 weeks ago php-pear-HTTP orphan, remi 3 weeks ago php-pear-HTTP-Client orphan, remi 3 weeks ago php-pear-HTTP-Upload orphan, remi 3 weeks ago php-pear-Net-Curl orphan, remi 3 weeks ago php-pear-Net-DIME orphan, remi 3 weeks ago php-pear-Net-FTP orphan, remi 3 weeks ago php-pear-Net-POP3 orphan, remi 3 weeks ago php-pear-Net-Ping orphan, remi 3 weeks ago php-pear-Net-URL-Mapperorphan, remi 3 weeks ago php-pear-Pager orphan, remi 3 weeks ago php-pear-SOAP orphan, remi 3 weeks ago php-pear-Validate orphan, remi 3 weeks ago php-pear-XML-Beautifierorphan, remi 3 weeks ago php-pear-XML-RSS orphan, remi 3 weeks ago php-pear-console-color2orphan, remi 3 weeks ago publican-icaro orphan, mayorga, 3 weeks ago williamjmorenor python-cement orphan, derks 8 weeks ago python-compositor orphan, fonts-sig, i18n- 9 weeks ago team, pnemade python-pytgorphan, sagitter 6 weeks ago python-robofab orphan, fonts-sig, i18n- 9 weeks ago team, jpokorny, pnemade python-ufo2fdk orphan, fonts-sig, i18n- 9 weeks ago team, pnemade qdigidoc orphan, anttix, kalev, 0 weeks ago
Re: Split translations to noarch packages?
On 29 April 2017 at 22:30, Reindl Harald wrote: > given that i run Fedora fpr a decade on everyting from production servers to > routers and desktops and reading all of your posts of the last week - well, > i have no idea what your problem is Looks like we have completely different jobs .. just accept this. However this aspect has nothing do with this topic. I can tell you only that there are plenty of examples where Solaris even with paid support is cheaper than Linux without support because in case of Linux to provide the same throughput needs to be used much more powerful and by this expensive hardware. Many workloads cannot be horizontally scaled so scaling service with hardware is only solution. Bigger hardware means not only bigger initial costs but higher costs of powering and cooling. In case of calculating costs of running routers or desktops on scale few units I don't think that anyone is thinking about those costs. Does it mean that Solaris should be used everywhere? Of course not!!! It would be idiotic. But again: this thread is not about me or which OS is better in exact context but about some exact technical aspects related to PM technologies. This topic is quite static/parallel/fixed/the same as it comes to management of some set of files used by running processes and operating system. As some problems on exactly this area have been already successfully solved on top of the Solaris there is no reason to be ashamed telling again "we can do better!". kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
On 29 April 2017 at 19:14, Reindl Harald wrote: > but you are coming in several threads and tell everybody that Fedora has to > be built completly different while the logical answer would be: well, if > everything in Fedora is not the way you like it then Fedora probably just > isn't for you? Is it really so hard to guess that Linux and Solaris have own niches on OS market and I'm kind of those guys which needs both OSes? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
On 29 April 2017 at 18:29, Neal Gompa wrote: > There's plenty of stuff going on in rpm.org upstream. You can look for > yourself: https://github.com/rpm-software-management/rpm Seems none is going to provide %doc and %lang() generalisation to allow mark more than current 5 classes of the files within packages like normal/regular file, %doc, %lang, %config and %ghost (%ghost is practically %config with some exact %verify rules). None is going towards provide IPS mediator functionality as well. > I've even personally contributed to it. If you feel there is missing > functionality, feel free to contribute and improve it. The upstream is > very active, with contributions from individuals from Red Hat/Fedora, > Mageia, SUSE/openSUSE, and even from BSD and Mac users! I cannot find some polite words when I'm trying to describe what I'm thinking when I'm looking on OpenSuse spec files .. but this is only my private opinion. However from the begging SuSE guys had always problems with understanding RPM as the technology (they've been using it for quite long time as dumb Slackware tgz PM replacement without significant changes on specs layer). I would not expect any significant help from other rpm based distros communities. Bottleneck is related to lack of people with enough deep/long PM exp. > As the saying goes: Talk is cheap! And this is what exactly I'm doing .. Problem is that most of the Linux folks have kind of natural Solaris "allergy' thinking about it as legacy or dead OS. Yep guys .. you are all wrong :-P Solaris was, is and will be because Linux cannot bring to the desks of the many engineers technologies which are available on Solaris OOTB .. ONLY. Truth is that on *many* areas Solaris still is more than decade ahead of Linux and all this progress happen after Solaris 10 (so don't tell me about your exp using Sol < 10 :) ) Just one example of last catch which is still in kind of embryonic stage on Linux: https://www.theregister.co.uk/2016/11/01/linux_in_2016_catches_up_to_solaris_from_2004/ Solaris userland changes are almost the same frequent as Fedora (https://java.net/projects/solaris-userland/sources/gate/history?) It is plenty of thing which could be adapted on Linux from Solaris. What I'm trying to do now is more or less prevent reinvention all those things second time :) > IPS may have some awesome capabilities, so why not add them to RPM? No > one has ever said we can't add best of breed features to RPM. This is not about awesomeness. Some features are *needed*. Full stop. Without those features more and more people will be bouncing own head over bigger and bigger packages fragmentation with growing web of dependencies and simple wasting time and not doing more important things. Really try to have look closer on IPS https://java.net/projects/ips/sources/pkg-gate/show/ If you will look closer you may see that size of the python code in which IPS is written is few times smaller with all additional python modules compare to whole RPM code (source or binary). Its is so simple because it bases on things which are still unimaginable in LinuxWorld(tm) like doing upgrade on separated clones of all affected FS not optionally like in ostree but unconditionally (ZFS on Solaris is now only available FS which is supported to install distro resources). Other set of features is related to 100% fixed set of actions (more or less analogues of %filetrigger* in rpm). For many RPM developer and packagers it will be total surprise that it was possible to build fully functional packaging layer *without* possibility to add even single customisation of the scriptlets fired during pre/post install/uninstall!!! Despite exactly those differences which affects semantics of install/upgrade/remove/roll back IPS code provides as well all necessary code of the services with package repository server, proxy, maintenance tools. All with encryption/authentication etc. Effectively IPS repo server it is set of resources served over http/https using apache + few small bits in apache settings .. no rocket science. As IPS started from much wider set of problems which even now not bothers typical Linux packager they (Sun developers) been able to make few significant code layer generalisations/simplifications. Parts which could be used on %doc/%lang generalisation (like IPS facets), and variants management (mediators) and few other gems like consolidations should be quite easy to extract from IPS and adapt on top RPM. However mediators will require to change paradigm of the package as archive to something which exist as the object in repository (IPS allows export from repo package as archive but they are used only on transferring resources between repos). With this step already done switching to the space in which packages provides multiarch resources sharing as much as it is only possible will be formality. IMO first step on this path could be stop using rpm and switch to use dnf only (few weeks ago I've showed here that no
Re: [RFC] delta-repository-metadata
Hi! I'm trying it under F25. First, thanks for working on it! It'd be a great feature. However: 1. I run it, and it was running for too long (probably 10 minutes!) with absolutely no log. I found that it is working on a 200M filelists.xml.gz.part file in DNF cache (which is apparently an uncompressed filelists file). And I guess it also downloads some data (at least the .zsync file, and probably also the new data) again without any reports to the user. 2. Finally, it finished, and this is the result: dnf update -vvv --disablerepo="rpmfusion*" --disablerepo=fedora cachedir: /var/cache/dnf Loaded plugins: local, noroot, needs-restarting, debuginfo-install, zsync, protected_packages, copr, playground, builddep, repomanage, Query, reposync, download, config-manager, generate_completion_cache DNF version: 1.1.10 repo: using cache for: localfedora not found deltainfo for: Local Fedora 25 - x86_64 not found updateinfo for: Local Fedora 25 - x86_64 repo: using cache for: group_rpm-software-management-deltamd not found deltainfo for: Copr repo for deltamd owned by @rpm-software-management not found updateinfo for: Copr repo for deltamd owned by @rpm-software-management repo: using cache for: _dnf_local not found deltainfo for: _dnf_local not found updateinfo for: _dnf_local Error: Cache-only enabled but no cache for 'updates' 3. I have not used -C option with DNF, so I wonder why it is complaining! Also, the filelists.xml.gz.part file is still there, so I guess zsync has not completed its task completely. Note: I've interrupted the command once the first time after installing the plugin, and run it again. I wonder if the interruption has anything to do with the problem. And I think if it is going to always take so much time for filelists file, maybe it is better to make zsync use the compressed file instead of uncompressed data for big files. Regards, Hedayat /*Igor Gnatenko*/ wrote on Thu, 27 Apr 2017 19:02:02 +0200: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello users and developers, We had presented deltametadata project at DevConf.CZ 2017[0], goal of this project is to minimize bandwidth required on clients to update repository metadata (repomd.xml, primary.xml, etc.) which would improve user experience with DNF. So, we have DNF plugin which acts How to try it? 1. dnf -y copr enable @rpm-software-management/deltamd 2. dnf -y install dnf-plugin-zsync If something doesn't work, look into /var/log/dnf.log. We would like you to try it out and give feedback, it is very important for us! Just send it as reply to this message.. P.S. F25 and above are supported [0] https://www.youtube.com/watch?v=l6uWxg3yMmw - -- Regards, lab-q Red Hat -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlkCJAoACgkQaVcUvRu8 X0wrGg/+Lvb/up8swQR6Nd9BacvrubhgELvOcOIsv/69aMPqe9cDqmAKUr33AWik zUWbAwpkS79BLLKjoxHTxR379Ubmj5mCWyuufg/HCgeCHOZwIBEQzqrBjwKMsIN+ ts6Qk7mo1bsgS3xozx/tRH+N1xhx1O+UInsDxS1qKQ5KIBntf/e8ZrgFL/fbjHYx /JVlz2p44tZxMHCsZP/hJv+DKV+AaY9/NcvLh2KBvpj75h8cVA3RkSE85YgNFNyD GJRjkzv+swmwWXVZMd0XNiCKKXn+qGooMsrrjAmbousG/Gd/DmTQekuO/hIkGZ+g rjSCPRjLXe+utD2lnqK5aWm1nJvaEUTjTAWKYAhV0mAAT/Y4Y8S2XcsdY6EXxiW6 iSYmXa4Rz4rTYiZ+K2XXYoEIGDVSN8C5lQyYy4Qqg2lnAyKDZ1567s/4fCz/IYpB rpDv+4jX1o3C8RY0XUuCYkt+/IpVH+1/DfkhWJCG2rNLDpnq5R7N4cryJg0MClW1 PUw24GJFbIwWnl6he0n+ShJ6wzZvd2jHwFBVj5a/718wech3YnIfSHf/xJeIE6Nn dK716wgmHUPyjCwk/cWQWdj5x99lMiDZJIXXFTu0zGLxXcHzz9MnZjDCv219u6XU Vj0dCKWa3SoLml+zmRkqb+T4acyyXlwPBahRFXN3qBhFpqoA/MY= =5ar8 -END PGP SIGNATURE- ___ 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
Fedora 26-20170429.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Failed openQA tests: 17/116 (x86_64), 7/23 (i386), 1/2 (arm) ID: 88783 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/88783 ID: 88797 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/88797 ID: 88798 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/88798 ID: 88809 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/88809 ID: 88812 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/88812 ID: 88813 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/88813 ID: 88815 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/88815 ID: 88826 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/88826 ID: 88827 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/88827 ID: 88829 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/88829 ID: 88863 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/88863 ID: 88876 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/88876 ID: 88879 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/88879 ID: 1 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1 ID: 3 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/3 ID: 4 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/4 ID: 7 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/7 ID: 8 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/8 ID: 9 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/9 ID: 88890 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/88890 ID: 88897 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/88897 ID: 88907 Test: i386 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/88907 ID: 88909 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/88909 ID: 88910 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/88910 ID: 88911 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/88911 Soft failed openQA tests: 10/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 88792 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/88792 ID: 88793 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/88793 ID: 88896 Test: i386 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/88896 ID: 88898 Test: i386 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/88898 ID: 88900 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/88900 ID: 88903 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/88903 ID: 88904 Test: i386 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/88904 ID: 88905 Test: i386 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/88905 ID: 88906 Test: i386 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/88906 ID: 88908 Test: i386 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/88908 Passed openQA tests: 91/116 (x86_64), 6/23 (i386) Skipped openQA tests: 9 of 141 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
On Sat, Apr 29, 2017 at 12:13 PM, Tomasz Kłoczko wrote: > On 28 April 2017 at 21:32, Matthew Miller wrote: >> You do keep saying that it's easy. What I'm saying is that it's easy to >> say things are easy, but... from experience, usually they are not. If >> it *is* that easy, why not make a proof of concept? In any case, taking >> them to the RPM project upstream is probably more fruitful than what >> amounts to effectively nagging people who are attempting to make >> improvements to _use_ within the existing functionality of the >> software. > > You see it is only one big hole in you logic .. IPS exist!!! > As long as you still going to refuse that IPS existence I must agree > with you that it is really hard .. however I'm not going to share your > pain because I'm using it on daily bases. > Just control question: did you ever try *one time* to have look on IPS > in meantime? > If not this conversation does not make any sense because it is like > trying to explain you taste of some dish you never been eating and > probably never going to try. > > FYI: no one working on RPM is interested extending its functionality > There's plenty of stuff going on in rpm.org upstream. You can look for yourself: https://github.com/rpm-software-management/rpm I've even personally contributed to it. If you feel there is missing functionality, feel free to contribute and improve it. The upstream is very active, with contributions from individuals from Red Hat/Fedora, Mageia, SUSE/openSUSE, and even from BSD and Mac users! As the saying goes: Talk is cheap! IPS may have some awesome capabilities, so why not add them to RPM? No one has ever said we can't add best of breed features to RPM. -- 真実はいつも一つ！/ 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: Split translations to noarch packages?
On 28 April 2017 at 21:32, Matthew Miller wrote: > You do keep saying that it's easy. What I'm saying is that it's easy to > say things are easy, but... from experience, usually they are not. If > it *is* that easy, why not make a proof of concept? In any case, taking > them to the RPM project upstream is probably more fruitful than what > amounts to effectively nagging people who are attempting to make > improvements to _use_ within the existing functionality of the > software. You see it is only one big hole in you logic .. IPS exist!!! As long as you still going to refuse that IPS existence I must agree with you that it is really hard .. however I'm not going to share your pain because I'm using it on daily bases. Just control question: did you ever try *one time* to have look on IPS in meantime? If not this conversation does not make any sense because it is like trying to explain you taste of some dish you never been eating and probably never going to try. FYI: no one working on RPM is interested extending its functionality (try to have look on what they are working on rpm 5.x on http://rpm5.org/). In other words you may expect that Project Modules with its new needs will have NULL support from RPM developers. Ergo: without changes to import some IPS functionalities like mediators which are able to check dependencies on switching variants this project is already sentenced to FAIL. Developers working on this project don't know about this or still refuses some basic facts and it may take them even few years until they will agree that without deeper changes in PM layer it will be not possible to reach goals of this project. Just my personal opinion: because IMO adding to RPM functionalities will require at least 2-3 full time developers for +1 year and it will be not possible to rewrite it easily (RPM have over complicated code). IMO more likely will be that within next few years some Linux folks will take IPS as it is and will start packaging Linux stuff using this PM software. It will be not a first time in Linux history when Linux will be borrowing something from Solaris. What you are guys trying to do with separating more and more noarch subpackages is moving whole PM technology to pre-RPM era (+~22 years). Really .. good luck with that. More packages -> more dependencies -> higher probability that something will fail within resolving those dependencies. As long as even few years ago disk space was kind of issue today it is nothing more than minor issue (even on small embedded systems it will be less and less problem). All those noarch separation will make more and more difficult use Linux software provided by Fedora. Just one example: try to press F1 on any GNOME application and quite possible that you will see nice small dialog box that help is not available. Only small percentage of the people will start scratching own head trying to ask "why?" And maybe few will find that it is because someone decided to separate help files from *all* GNOME desktop application. Long term result: less and less people will care about those help pages its quality or translations to other languages .. Yes you can start adding missing here dependencies but easier would be just fix those issues by merge these resources because current separations adds only complexity in spec files. After such merge if someone hates to have installed any documentation it will be very good solution by just add one line in /etc/rpm/rpmrc and reinstall all packages by "rpm -qa | xargs dnf reinstall -y" (it will take 20min to maybe 2-3h depends on network bandwidth and CPU speed but recipe to do this is b*dy easy). Cases when someone is using Linux with 32/64 bits binaries already is decreasing. Investing time in more separation is already lost effort. You may ignore me or name me as an idiot/fool (as some other people in this thread not able to add any new argument) but I'm only messenger .. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: gnustep-base 1.25.0 update
Am 29.04.2017 um 16:01 schrieb Antonio Trande: Hello. gnustep-base must be updated to the release 1.25.0. I created a buildroot-override (https://bodhi.fedoraproject.org/overrides/gnustep-base-1.25.0-2.fc26) for rebuilding its dependencies so, please, rebuild and commit a new release of following packages in f26: unar (successfully rebuilt) openvpn-auth-ldap (successfully rebuilt) raidem (rebuild failed) I've rebuilt unar and openvpn-auth-ldap packages on fc26 and already added them to your update. For raidem I've added a simple, but effective patch to fix -Werror=format-security and rebuilt it on fc27 and fc26, too; will add the build to your update as soon as it is finished. Cheers, Björn ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
gnustep-base 1.25.0 update
Hello. gnustep-base must be updated to the release 1.25.0. I created a buildroot-override (https://bodhi.fedoraproject.org/overrides/gnustep-base-1.25.0-2.fc26) for rebuilding its dependencies so, please, rebuild and commit a new release of following packages in f26: unar (successfully rebuilt) openvpn-auth-ldap (successfully rebuilt) raidem (rebuild failed) -- -- Antonio Trande sagitter AT fedoraproject dot org See my vCard. <> 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: DNF translation
I think that developers should be asked this question. As DNF is a software originally made by Fedora people I think it's correct to crosspost to devel@fpo hoping to get an answer from the DNF authors or at least from somebody who can explain what they meant. Just to summarize the story: somebody please explain us what is "a payload factory" in this context. Regards, Rafal 29.04.2017 03:07 Daniel López wrote: > > > sometimes payload is used as capacity > > > > i think it means the number exceeds the capacity for , lets say, certain > number of packages. > > > > Not really sure. Have you solved it already? > > > > > > > - > De: Máximo Castañeda > Enviado: miércoles, 12 de abril de 2017 07:30:11 a. m. > Para: Fedora Translation Project List > Asunto: Re: DNF translation > > FWIW, I've translated it to something that back in English would be > like "no data manager found for %s". From the code[1], it looks like > there are different types of repos or downloadable "stuff" (payload), > that can each have a different "manager" (factory), such as a normal > rpm and a deltarpm. > > [1] > https://github.com/rpm-software-management/dnf/blob/master/dnf/repo.py#L104 > https://github.com/rpm-software-management/dnf/blob/master/dnf/repo.py#L104 > > 2017-04-12 13:39 GMT+02:00 Zdenek Chmelar : > > Hello all > > > > The DNF project has one sentence which I'm not able to reasonably > > translate. I think I do not understand the sentence meaning properly. I > > have checked French and German translations in order to understand the > > meaning better but those languages didn't translate that sentence yet. > > > > So what's the magic sentence I speak about? > > "no matching payload factory for %s" (message with number #547) > > > > If anyone could explain what means "payload factory" in relation to DNF, I > > would be very thankful ;-) > > > > Thanks > > Z. > > ___ > > trans mailing list -- tr...@lists.fedoraproject.org > > To unsubscribe send an email to trans-le...@lists.fedoraproject.org > ___ > trans mailing list -- tr...@lists.fedoraproject.org > To unsubscribe send an email to trans-le...@lists.fedoraproject.org > > ___ > trans mailing list -- tr...@lists.fedoraproject.org > To unsubscribe send an email to trans-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Alternative Arch update
On Fri, 28 Apr 2017 17:34:33 -0500 Dennis Gilmore wrote: > Hi All, > > Just letting you all know that as part of the redefinition of > Alternative Architectures[1] we have just enabled the building of > s390x in primary koji. this is the last new architecture we are > planning to enable at this point. s390x will be added to rawhide > composes early next week. If you have any questions or experience any > issues and wan releng to provide assistance, please contact us by one > of the documented channels[2]. and same as with the other alternative arches merges, if there is potentially an architecture specific issue, don't hesitate to ask us, the alternative arches team(s) [3], what should be the best way to solve the problem. > With the import being done now, it has been decided that s390x is too > late for Fedora 26, as such it will be built and shipped from > s390.koji.fedoraproject.org in the Fedora 26 cycle we brought in > aarch64, ppc64 and ppc64le to primary koji. This means that the arm > and ppc koji's will be used for updates until Fedora 25 goes End of > Life and will be shut down at that point. The s390 koji will live on > until Fedora 26 goes EOL. [3] https://fedoraproject.org/wiki/Architectures#Alternative_Architectures Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
