Re: ExecStart line in systemd service files.
On Fri, 2013-08-09 at 16:56 +0100, আনন্দ কুমার সমাদ্দার Ananda Samaddar wrote: > On Fri, 9 Aug 2013 17:52:23 +0200 > Lennart Poettering wrote: > > > On Fri, 09.08.13 16:34, আনন্দ কুমার সমাদ্দার Ananda Samaddar > > (asamad...@myopera.com) wrote: > > > > > > I have no idea about hte package in question, but be aware that > > > > you need to pass --prefix=/usr (among other things) to configure > > > > for all packages packaged for Fedora. This is documented in more > > > > detail in the Fedora packaging guidelines. > > > > > > > > If you end up with /usr/local in a path then this indicates that > > > > you didn't pass --prefix=/usr correctly or you found a bug in the > > > > upstream build scripts. > > > > > > > > Lennart > > > > > > > > > > The package configures and builds fine. The default %configure > > > macro automatically sets the prefix to /usr. Michael was saying > > > that the binary path in the service file should be set by the > > > configure or make commands so this would require some knowledge of > > > autoconf. > > > > If the unit files are shipped upstream, and are hardcoded to point to > > /usr/local, then that's an upstream bug really. Please ask them to > > generate them with sed or so with the right path filled in. > > > > Lennart > > > > The unit file did point to /usr/local/bin. I contacted upstream and > they changed it to /usr/bin. I was then led to believe that the path > had to be generated during the build process as I've mentioned > previously and it's not satisfactory to include a manually written unit > file with the path already set. If it is I'll inform upstream and this > issue can be closed. Well, define 'acceptable'. It's bad form; a hardcoded path is never going to be right for all your potential users (those who compile from source and those who use distro packages). Roughly, they just want a progname.service.in file which has the path as a variable - I forget what it's called in autotools language, I think $_bindir or something like that - and then a bit of configuration in, IIRC, Makefile.am which tells autotools to generate progname.service from progname.service.in and substitute the variable. It's not difficult stuff, there are a million codebases out there you could use to cargo cult the relevant bits from. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F19 server install experience
On Fri, 2013-08-09 at 15:54 -0700, Samuel Sieb wrote: > I realize it's been a while since F19 was released but I finally got > around to do a server install. Since there have been a few negative > reviews here of the installation process I thought it might be nice to > have a mostly positive one. Here are my observations: > > VLAN setup for installing! Yay! However, after rebooting, > NetworkManager wasn't able to bring it up, something about not knowing > the "virtual interface name". Turned out to be the ethernet interface > name changed from what it was at install time. This would be the rather brown-paper-bag-ish https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=965718 . Last I checked we were still working out the precise implications of that one. This sounds like another of them. > Didn't detect my timezone. Not a big deal, but I was hoping it would > since there's been some discussion here about it working. We'd probably need the apparent public IP address of the system you were installing on to debug this one. > I'm reinstalling an existing server, so used the custom partitioning. > The only problem I had here was that I clicked on the existing /home > partition to add it to the new install but then couldn't figure out what > to do. All I saw on the right was lots of disabled form items. > Eventually I read the instructions carefully You damn dirty liar. You are CLEARLY not a Fedora user. > and then looked at the > mount point entry again and saw that it wasn't disabled. I wonder if > there is some way to make it more obvious... Trumpets? :) > After starting the install, I went to enter the root password. As I was > doing so, the interface appeared to freeze. I switched through the > consoles and when I got back the interface was working again and the > keys that I had typed had shown up. Yeah, that happens sometimes. I've never bothered reporting it, but if you do I'll subscribe to your newsletter. I think the root PW UI can block on partitioning operations happening behind it. > One odd thing I noticed while > cycling through the consoles was that console 6 had a login prompt on > it. I didn't actually try logging in. > > The progress bar is strange. All the package installing barely made it > past a quarter of the way. That progress info is coming straight from yum (it's basically the same 'progress' you get when doing a 'yum update'). Because it still has to do its "verify" and "clean" steps, yeah, you're a long way behind 100% when it's just done "installing". Remember, there are lies, damn lies, statistics, and progress bars... > Other than the ethernet interface naming issue, just minor cosmetic > issues. Thanks to everybody involved in getting the installer in such > nice shape. Glad you enjoyed it! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Sat, Aug 17, 2013 at 1:41 AM, "Jóhann B. Guðmundsson" wrote: > On 08/15/2013 03:55 PM, Stephen John Smoogen wrote: > Some form of middle ground of this is what we have currently implemented in > QA and test for but even there we cannot "guarantee" anything, like if we > take the default desktop installation how well can Gnome itself handle > upgrades between releases ( think for example *conf schema changes here ) "guarantee" is a worse word then supported we cannot guarantee that Fedora boots on your system at all. People seem to pay to much attention to the word "supported" .. it basically means "that is what should work, if we find out that it doesn't we fix it before the release or even slip until it gets fixed". It does not mean that works in all cases and is "bug free". Not supporting upgrades and putting no effort into it would render Fedora pretty much the most useless distro ever. Re installing every 6 months is simply to inconvenient for many users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[ACTION REQUIRED] Retiring packages for Fedora 20 including FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 20 v2)
Due to missing FTBFS bug reports for Fedora 18 and a bug in scripting, FTBFS packages were missing in previous reports. According to https://fedoraproject.org/wiki/Fails_to_build_from_source?rd=FTBFS#Package_Removal_for_Long-standing_FTBFS_bugs removing long standing FTBFS packages might be delayed until the Alpha release, which is planned for in about a month. Nevertheless, please fix packages ASAP. The following packages are orphaned or did not build for two releases and will be retired when Fedora (F20) is branched, 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 According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2013-08-20. The packages will be retired shortly before. Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Package(co)maintainers === alsa-oss orphan, perex becicku, mcepl curry gemi, oliver eclipse-phpeclipsembooth, swagiaal eclipse-veditor chitlesh, shakthimaan, swagiaal examiner orphan firmware-extract orphan, mebrown, praveenp firstboot orphan, msivak, mgracik, clumens, bcl fpaste-server orphan, nb, jsteffan gkrellm-timestamp orphan guiloader orphan justmoon orphan, mmahut libclaw lkundrak, xavierb libgarmin fab libpng12 orphan, phracek libvpdemunson, hegdevasant, fkocina, lnykryn, rrakus, jskala lsvpd emunson, hegdevasant, fkocina, lnykryn, wolfy, rrakus, jskala lybnizorphan mars-sim orphan, mmahut miau orphan mod_mono chkr nautilus-sendto-trac mbooth open-cobols4504kr openstack-tempo orphan, vaneldik, josecastroleon, markmc osgal orphan petitboot dwmw2, tbreeds, jwboyer python-pylons kylev, cicku python3-cherrypy orphan simulavr ndim smart athimm, scop synce-connector awjb tango-icon-theme cwickert tango-icon-theme-extras cwickert vbladeorphan The following packages require above mentioned orphaned/FTBS packages: Depending on: alsa-oss modplugtools (maintained by: scop) modplugtools requires libaoss.so.0 modplugtools requires alsa-oss-devel = 1.0.17-9.fc20 mumble (maintained by: chkr, chkr, jgold) mumble requires alsa-oss-devel = 1.0.17-9.fc20 Depending on: guiloader guiloader-c++ (maintained by: orphan) guiloader-c++ requires libguiloader.so.1 guiloader-c++ requires guiloader-devel = 2.99.0-2.fc17 guiloader-c++-devel requires guiloader-devel = 2.99.0-2.fc17, pkgconfig(guiloader) = 2.99.0 Depending on: libclaw plee-the-bear (maintained by: jwrdegoede, spot) plee-the-bear requires libclaw_application.so.1, libclaw_configuration_file.so.1, libclaw_dynamic_library.so.1, libclaw_graphic.so.1, libclaw_logger.so.1, libclaw_net.so.1, libclaw_tween.so.1 plee-the-bear requires libclaw-devel = 1.7.0-5.fc17 Depending on: python-pylons pytho
[ACTION REQUIRED] Retiring packages for Fedora 20 including FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 20 v2)
(Sorry, I forgot to add the package maintainers address to Bcc, therefore this message will appear twice on the devel mailing list) Due to missing FTBFS bug reports for Fedora 18 and a bug in scripting, FTBFS packages were missing in previous reports. According to https://fedoraproject.org/wiki/Fails_to_build_from_source?rd=FTBFS#Package_Removal_for_Long-standing_FTBFS_bugs removing long standing FTBFS packages might be delayed until the Alpha release, which is planned for in about a month. Nevertheless, please fix packages ASAP. The following packages are orphaned or did not build for two releases and will be retired when Fedora (F20) is branched, 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 According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2013-08-20. The packages will be retired shortly before. Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Package(co)maintainers === alsa-oss orphan, perex becicku, mcepl curry gemi, oliver eclipse-phpeclipsembooth, swagiaal eclipse-veditor chitlesh, shakthimaan, swagiaal examiner orphan firmware-extract orphan, mebrown, praveenp firstboot orphan, msivak, mgracik, clumens, bcl fpaste-server orphan, nb, jsteffan gkrellm-timestamp orphan guiloader orphan justmoon orphan, mmahut libclaw lkundrak, xavierb libgarmin fab libpng12 orphan, phracek libvpdemunson, hegdevasant, fkocina, lnykryn, rrakus, jskala lsvpd emunson, hegdevasant, fkocina, lnykryn, wolfy, rrakus, jskala lybnizorphan mars-sim orphan, mmahut miau orphan mod_mono chkr nautilus-sendto-trac mbooth open-cobols4504kr openstack-tempo orphan, vaneldik, josecastroleon, markmc osgal orphan petitboot dwmw2, tbreeds, jwboyer python-pylons kylev, cicku python3-cherrypy orphan simulavr ndim smart athimm, scop synce-connector awjb tango-icon-theme cwickert tango-icon-theme-extras cwickert vbladeorphan The following packages require above mentioned orphaned/FTBS packages: Depending on: alsa-oss modplugtools (maintained by: scop) modplugtools requires libaoss.so.0 modplugtools requires alsa-oss-devel = 1.0.17-9.fc20 mumble (maintained by: chkr, chkr, jgold) mumble requires alsa-oss-devel = 1.0.17-9.fc20 Depending on: guiloader guiloader-c++ (maintained by: orphan) guiloader-c++ requires libguiloader.so.1 guiloader-c++ requires guiloader-devel = 2.99.0-2.fc17 guiloader-c++-devel requires guiloader-devel = 2.99.0-2.fc17, pkgconfig(guiloader) = 2.99.0 Depending on: libclaw plee-the-bear (maintained by: jwrdegoede, spot) plee-the-bear requires libclaw_application.so.1, libclaw_configuration_file.so.1, libclaw_dynamic_library.so.1, libclaw_graphic.so.1, libclaw_logger.so.1, libclaw_net.so.1
Re: [ACTION REQUIRED] Retiring packages for Fedora 20 v2
On Fri, Aug 16, 2013 at 10:26:45PM +0200, Kalev Lember wrote: > On 08/16/2013 10:15 PM, Till Maas wrote: > > On Fri, Aug 16, 2013 at 03:17:42PM -0400, Bill Nottingham wrote: > > > >> FTBFS packages need: > >> > >> 1) a list gathered by pruning the old F18FTBFS bug, or noting what things > >> still have earlier dist tags > > > [snip] > > Nevertheless, as far as I can see there is nothing to do wrt FTBFS for > > F20. > > The following repoquery shows a number of packages that still have .fc17 > disttags in rawhide and have likely been failing in mass rebuilds: I see, there was a bug in my script and I sent a new report to give maintainers a heads up as soon as possible. Nevertheless, since the FTBFS packages do not seem to have received bug reports, I propose to delay the removal of the FTBFS packages until the Alpha Change Deadline (no earlier than 2013-09-03) to work things out. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Retiring packages for Fedora 20 including FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 20 v2)
在 2013-8-17 PM5:00，"Till Maas" 写道： > becicku, mcepl Please don't retire it, I'm planning an update these days. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Old packages remain on the mirrors for one week
On Fri, 16 Aug 2013 16:57:38 -0600 Kevin Fenzi wrote: > > Well, I think many folks won't like the extra disk space used. More than likely, but if they are interested in testing maybe not.? > > I think it would take something like yum-plugin-local to have a > proper repo that yum could see to downgrade things from though. > (I've not tried your suggestion above to see if it would work for > downgrades or not) Will do some specific testing on this isolated F19 box till Oct.? Then attempt a downgrade, with --keep=10 But it has worked from my nfs lan yum server (cureently offline) -- Regards, Frank "When in doubt PANIC!" I check for new mail app. 20min www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Old packages remain on the mirrors for one week
I hope we can remain the rawhide packages for downgrade. Any ideas? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Old packages remain on the mirrors for one week
On Fri, Aug 16, 2013 at 6:48 AM, Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mon, 12 Aug 2013 14:47:03 +0100 > Richard Hughes wrote: > >> Hi all, >> >> I'd like to ask for comments on a feature I need for the Fedora >> Application Installer. The current yum backend in PackageKit does >> something like this: >> >> * yum install foo >> * depsolve transaction using cached metadata >> * download foo-0.1.noarch.rpm >> * error! foo-0.1.noarch.rpm doesn't exist >> * download latest repomd, primary >> * re-depsolve >> * download latest filelists >> * continue to re-depsolve >> * download foo-0.2.noarch.rpm >> * install foo using librpm >> >> Now, we do this as the metadata is cached on the client side for up to >> a week as we don't want to unconditionally update the metadata for >> every transaction, but we don't know if we can download the package >> without downloading all the metadata beforehand. This is incompatible >> with the swish UX in the application installer where we can search for >> things straight away without having "Downloading..." in the UI >> appearing at odd times. So my proposal is thus: >> >> 1. We retain old packages on the mirrors for a minimum of 7 days. > > without completely rewriting how we compose the trees this is not a > possibility. Bill's mail reads a bit different ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Merging freediams into freemedforms
Hi, I maintain two packages for the fedora-medical SIG that fall under the "freemedforms[1]" project. At the moment, these are packaged separately: 1. freemedforms[2]: provides freemedforms-emr and pulls in freediams 2. freediams[3] Now, freemedforms-emr and freediams are both built from the same source, and use the same internal libraries. Currently, I first build freemedforms-emr and the common libraries (spec[4]) and then build freediams (spec[5]), pointing to these libraries. Recently, with the 0.9.0-beta1 release, upstream sent me a new spec and suggested I use one spec to build both freedmedforms and freediams, and provide freediams as a subpackage. I've built freemedforms already, and I'm in the process of updating freediams now. I think it's a good idea, since they'll always move hand in hand. The build process will be simpler, and so will maintaining the package and updates. What do you folks think? Should I go ahead and retire(obsolete) freediams and provide it as a subpackage in freemedforms? I don't see any issues with this, but wanted to consult you folks to be sure before I go ahead and make the changes. [1] http://freemedforms.com/en/start [2] https://admin.fedoraproject.org/pkgdb/acls/bugs/freemedforms [3] https://admin.fedoraproject.org/pkgdb/acls/bugs/freediams [4] http://pkgs.fedoraproject.org/cgit/freemedforms.git/tree/freemedforms.spec [5] http://pkgs.fedoraproject.org/cgit/freediams.git/tree/freediams.spec -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Retiring packages for Fedora 20 including FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 20 v2)
On 17 August 2013 10:00, Till Maas wrote: > Due to missing FTBFS bug reports for Fedora 18 and a bug in scripting, > FTBFS packages were missing in previous reports. According to > > https://fedoraproject.org/wiki/Fails_to_build_from_source?rd=FTBFS#Package_Removal_for_Long-standing_FTBFS_bugs > removing long standing FTBFS packages might be delayed until the Alpha > release, which is planned for in about a month. Nevertheless, please fix > packages ASAP. > > The following packages are orphaned or did not build for two > releases and will be retired when Fedora (F20) is branched, 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 > > According to https://fedoraproject.org/wiki/Schedule branching will > occur not earlier than 2013-08-20. The packages will be retired shortly > before. > > Note: If you received this mail directly you (co)maintain one of the > affected > packages or a package that depends on one. > > Package(co)maintainers > === > eclipse-phpeclipsembooth, swagiaal > eclipse-veditor chitlesh, shakthimaan, swagiaal I've fixed eclipse-veditor in F19 and F20. I'm thinking of retiring eclipse-phpeclipse anyway -- upstream is generally unresponsive and the project often seems moribund so I suspect Eclipse PDT is *much* better than PHPEclipse these days If anyone is still using eclipse-phpeclipse, I urge you to try out http://projects.eclipse.org/projects/tools.pdt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Old packages remain on the mirrors for one week
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 17 Aug 2013 13:14:14 +0200 drago01 wrote: > On Fri, Aug 16, 2013 at 6:48 AM, Dennis Gilmore > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Mon, 12 Aug 2013 14:47:03 +0100 > > Richard Hughes wrote: > > > >> Hi all, > >> > >> I'd like to ask for comments on a feature I need for the Fedora > >> Application Installer. The current yum backend in PackageKit does > >> something like this: > >> > >> * yum install foo > >> * depsolve transaction using cached metadata > >> * download foo-0.1.noarch.rpm > >> * error! foo-0.1.noarch.rpm doesn't exist > >> * download latest repomd, primary > >> * re-depsolve > >> * download latest filelists > >> * continue to re-depsolve > >> * download foo-0.2.noarch.rpm > >> * install foo using librpm > >> > >> Now, we do this as the metadata is cached on the client side for > >> up to a week as we don't want to unconditionally update the > >> metadata for every transaction, but we don't know if we can > >> download the package without downloading all the metadata > >> beforehand. This is incompatible with the swish UX in the > >> application installer where we can search for things straight away > >> without having "Downloading..." in the UI appearing at odd times. > >> So my proposal is thus: > >> > >> 1. We retain old packages on the mirrors for a minimum of 7 days. > > > > without completely rewriting how we compose the trees this is not a > > possibility. > > Bill's mail reads a bit different ... I suggest you re-read Bills email. the non-trivial changes are completely redoing how we compose the trees. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIPk6wACgkQkSxm47BaWfd0+ACghewKlJcOqJQHMC2N4uq4h/UJ UyAAnApfCP3Syivq9gw19sjqP/DTsh/N =g/Rt -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Old packages remain on the mirrors for one week
On Sat, Aug 17, 2013 at 5:15 PM, Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sat, 17 Aug 2013 13:14:14 +0200 > drago01 wrote: > >> On Fri, Aug 16, 2013 at 6:48 AM, Dennis Gilmore >> wrote: >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA1 >> > >> > On Mon, 12 Aug 2013 14:47:03 +0100 >> > Richard Hughes wrote: >> > >> >> Hi all, >> >> >> >> I'd like to ask for comments on a feature I need for the Fedora >> >> Application Installer. The current yum backend in PackageKit does >> >> something like this: >> >> >> >> * yum install foo >> >> * depsolve transaction using cached metadata >> >> * download foo-0.1.noarch.rpm >> >> * error! foo-0.1.noarch.rpm doesn't exist >> >> * download latest repomd, primary >> >> * re-depsolve >> >> * download latest filelists >> >> * continue to re-depsolve >> >> * download foo-0.2.noarch.rpm >> >> * install foo using librpm >> >> >> >> Now, we do this as the metadata is cached on the client side for >> >> up to a week as we don't want to unconditionally update the >> >> metadata for every transaction, but we don't know if we can >> >> download the package without downloading all the metadata >> >> beforehand. This is incompatible with the swish UX in the >> >> application installer where we can search for things straight away >> >> without having "Downloading..." in the UI appearing at odd times. >> >> So my proposal is thus: >> >> >> >> 1. We retain old packages on the mirrors for a minimum of 7 days. >> > >> > without completely rewriting how we compose the trees this is not a >> > possibility. >> >> Bill's mail reads a bit different ... > > I suggest you re-read Bills email. the non-trivial changes are > completely redoing how we compose the trees. Seems like we both have a different definition for the word "complete". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Old packages remain on the mirrors for one week
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 Aug 2013 23:48:46 -0500 Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mon, 12 Aug 2013 14:47:03 +0100 > Richard Hughes wrote: > > > Hi all, > > > > I'd like to ask for comments on a feature I need for the Fedora > > Application Installer. The current yum backend in PackageKit does > > something like this: > > > > * yum install foo > > * depsolve transaction using cached metadata > > * download foo-0.1.noarch.rpm > > * error! foo-0.1.noarch.rpm doesn't exist > > * download latest repomd, primary > > * re-depsolve > > * download latest filelists > > * continue to re-depsolve > > * download foo-0.2.noarch.rpm > > * install foo using librpm > > > > Now, we do this as the metadata is cached on the client side for up > > to a week as we don't want to unconditionally update the metadata > > for every transaction, but we don't know if we can download the > > package without downloading all the metadata beforehand. This is > > incompatible with the swish UX in the application installer where > > we can search for things straight away without having > > "Downloading..." in the UI appearing at odd times. So my proposal > > is thus: > > > > 1. We retain old packages on the mirrors for a minimum of 7 days. > > without completely rewriting how we compose the trees this is not a > possibility. > > > 2. We regenerate the metadata on every compose like before > > 3. We only include the latest package version in the metadata > > this would need the tools to be completely rewritten also. > > > 4. If the user is installing an "old" package we check if the new > > package is a security or important update and re-download all > > metadata if so > this means downloading all the metadata an option here would be to have a separate security updates repo. we would need to take steps to make sure it doesn't result in broken deps. but it would mean you could download security updates metadata separately which would be much smaller and simpler to consume. It would require some separate tags in koji and changes to the bodhi masher processes to make the security repo separately. this would have the side effect that we could quickly push out important security updates. > > Point 3 means that the metadata size does not explode, and CLI tools > > like yum don't spend minutes depsolving a much larger set of > > packages. Although this increases the amount of space required on > > the mirrors (by about 15% for fedora-19 by my approximation), the > > amount of bandwidth saved is huge. By my calculations, over the > > last 7 weeks [with ~10 offline updates, and hundreds of 'yum' > > commands] over 60% of my traffic from the mirrors is metadata! > > > > FWIW; 1,2,3 is what Debian and Ubuntu do. Comments welcome, thanks. > > > > Richard > > with the schedules as they have been I really dont know when Id get > any time to work on the tooling for composing. certainly not before > Fedora 21 likely later than that. > > Dennis > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > > iEYEARECAAYFAlINry4ACgkQkSxm47BaWffHQACfQizrrtfRi+qX4+wBK6lQyUQh > jMoAniirXFSRfkcgc63o0TIzISSBrtQI > =s6rn > -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIPlLAACgkQkSxm47BaWfcL5ACglmuk1eD7/VWD+9k7xqMR1OY2 ZagAoL6Qgp+TO8DkPCUJOoJcEhi6Y0GC =SUJG -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Suggestion: bmap files and bmaptool
On Thu, Aug 15, 2013 at 12:34:26PM -0500, Eric Sandeen wrote: > But then there's the issue of transporting these sparse files > around. We have had the same problem in the past with large e2image > metadata image files, which may be terabytes in length, with only > gigabytes or megabytes of real data. e2image _itself_ creates a > sparse file, but bzipping it or rsyncing it still processes > terabytes of zeros, and loses all notion of sparseness. xz preserves sparseness. We use it for preserving and compressing virt-sparsify'd images. > Another approach which might (?) be more robust, is to somehow > encode that sparseness in a single file format that can be > transported/compressed/copied w/o losing the sparseness information, > and another tool to operate efficiently on that format at the > destination, either by unpacking it to a normal sparse file or > piping it to some other process. qcow2 :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
some build fix for FTBFS in rawhide
hi uploaded some patch for the following packages, which have had this problem "FTBFS in rawhide" geronimo-validation https://bugzilla.redhat.com/show_bug.cgi?id=992345 htmlunit https://bugzilla.redhat.com/show_bug.cgi?id=992488 jamonapi https://bugzilla.redhat.com/show_bug.cgi?id=992588 json-lib https://bugzilla.redhat.com/show_bug.cgi?id=992642 jtype https://bugzilla.redhat.com/show_bug.cgi?id=992647 proxool https://bugzilla.redhat.com/show_bug.cgi?id=992827 if you can applied these ones, with the aim of being able to close regards gil <>-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: some build fix for FTBFS in rawhide
Il 17/08/2013 19:27, punto...@libero.it ha scritto: hi uploaded some patch for the following packages, which have had this problem "FTBFS in rawhide" geronimo-validation https://bugzilla.redhat.com/show_bug.cgi?id=992345 htmlunit https://bugzilla.redhat.com/show_bug.cgi?id=992488 jamonapi https://bugzilla.redhat.com/show_bug.cgi?id=992588 json-lib https://bugzilla.redhat.com/show_bug.cgi?id=992642 jtype https://bugzilla.redhat.com/show_bug.cgi?id=992647 proxool https://bugzilla.redhat.com/show_bug.cgi?id=992827 if you can applied these ones, with the aim of being able to close regards gil forgot these: objenesis https://bugzilla.redhat.com/show_bug.cgi?id=992389 ehcache-sizeof-agent https://bugzilla.redhat.com/show_bug.cgi?id=992185 multithreadedtc https://bugzilla.redhat.com/show_bug.cgi?id=992307 <>-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
bug filed against "distribution"
since i have enough of bugzilla-mails as response of bugreports containing referecnes to any Fedora version but not the reported i consider this as bug in the distribution itself https://bugzilla.redhat.com/show_bug.cgi?id=998035 *at least* a "we do not fix this in F18 because " or "it will most likely done in the next package-update for Fq8" would be what anybody who is wasting his time for verify things in the distribution and report bugs/guideline-violations should be a response ___ hence i even do not understand why not every maintainer is reading http://fedoraproject.org/wiki/Packaging:Guidelines#PIE and after logout from the DE calls "checksec --proc-all" and *MUST enable* in the guidelines is no opt-in as well as read things like http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html thanks god, some of the packages i reported in the last months are in the meantime fixed - but why maintainers and/or at least QA do not care that the guidelines are respected? "Your package accepts/processes untrusted input" qualifies firefox too and until now https://bugzilla.redhat.com/show_bug.cgi?id=973458 had only a blunty response "I mean the fix is need for xulrunner package, not for the firefox one" - well, the same maintainer for both ___ If your package meets any of the following criteria you *MUST enable* the PIE compiler flags: * *Your package is long running* This means it's likely to be started and keep running until the machine is rebooted, not start on demand and quit on idle. * Your package has *suid binaries*, or binaries with *capabilities*. * *Your package runs as root* If your package meets the following criteria you should consider enabling the PIE compiler flags: * Your package accepts/processes untrusted input ___ signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bug filed against "distribution"
On Fri, 16 Aug 2013 22:05:57 +0200 Reindl Harald wrote: > since i have enough of bugzilla-mails as response of bugreports > containing referecnes to any Fedora version but not the reported > i consider this as bug in the distribution itself > > https://bugzilla.redhat.com/show_bug.cgi?id=998035 > > *at least* a "we do not fix this in F18 because " > or "it will most likely done in the next package-update for Fq8" > would be what anybody who is wasting his time for verify things > in the distribution and report bugs/guideline-violations should > be a response Why not simply ask in a bug comment? "Thanks for the f19/f20 updates, but I reported against f18, is there any way you can backport this fix to f18 for me please?" I think most maintainers would answer that and try and accommodate you. Perhaps they missed that it was filed against f18, or they thought that you just wanted it fixed in newer releases, etc. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bug filed against "distribution"
Am 17.08.2013 20:17, schrieb Kevin Fenzi: > On Fri, 16 Aug 2013 22:05:57 +0200 > Reindl Harald wrote: > >> since i have enough of bugzilla-mails as response of bugreports >> containing referecnes to any Fedora version but not the reported >> i consider this as bug in the distribution itself >> >> https://bugzilla.redhat.com/show_bug.cgi?id=998035 >> >> *at least* a "we do not fix this in F18 because " >> or "it will most likely done in the next package-update for Fq8" >> would be what anybody who is wasting his time for verify things >> in the distribution and report bugs/guideline-violations should >> be a response > > Why not simply ask in a bug comment? > > "Thanks for the f19/f20 updates, but I reported against f18, is there > any way you can backport this fix to f18 for me please?" > > I think most maintainers would answer that and try and accommodate you. > Perhaps they missed that it was filed against f18, or they thought that > you just wanted it fixed in newer releases, etc. becuase it happens *regualary* and not from time to time and not depending on package/maintainer and that is a wron gbehavior which should be made clear insinde the distribution people like i complain, others simply no longer reporrt bugs if it happens repeatly signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F19 server install experience
On 08/17/2013 12:28 AM, Adam Williamson wrote: VLAN setup for installing! Yay! However, after rebooting, NetworkManager wasn't able to bring it up, something about not knowing the "virtual interface name". Turned out to be the ethernet interface name changed from what it was at install time. This would be the rather brown-paper-bag-ish https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=965718 . Last I checked we were still working out the precise implications of that one. This sounds like another of them. I should remember to check common bugs, but since I follow this list I'm normally familiar with the existing issues. But after looking at the entry, it wouldn't have been helpful to my case since it says there shouldn't be any issues. In this case, the problem is cross-interface matching. The ethernet interface was created with one name and the vlan references that one. However, after rebooting the ethernet interface has a different name, so the vlan can't find it and fails. Didn't detect my timezone. Not a big deal, but I was hoping it would since there's been some discussion here about it working. We'd probably need the apparent public IP address of the system you were installing on to debug this one. I just tested the ip against the fedora geoip service and it returns the correct info. I wonder if there is something timing related. Since I had to setup the vlan interface before it had internet access, maybe it was too late for the lookup. Eventually I read the instructions carefully You damn dirty liar. You are CLEARLY not a Fedora user. It was my last resort! And since I was installing the gateway server, I didn't have internet access to use Google or ask on the mailing list. ;-) and then looked at the mount point entry again and saw that it wasn't disabled. I wonder if there is some way to make it more obvious... Trumpets? :) Sure! I don't know, maybe a different color, but that gets into other issues... It's not a huge deal, but in the sea of grey, the one black label didn't stick out much. One odd thing I noticed while cycling through the consoles was that console 6 had a login prompt on it. I didn't actually try logging in. Any thoughts on this one? It was rather surprising to find a login prompt during the installing process. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Proposal for new package group: Development:Formal Methods Tools
I would like to edit comps.xml to add a new package group for the tools that have already been packaged by the Formal Methods SIG. I propose that the group be located under the "Development" category. Id: formal-methods-tools Name: Formal Methods Tools Description: These tools for the development of hardware and software are based on Formal proof methods. The default for the group itself will be false (will not be installed by default). Find below a list of package names to be included in the group with the proposed level (D for default, O for optional). Given that the scope of application of these tools is very diverse, it made sense to me to make most of the packages optional; O alt-ergo O alt-ergo-gui O coq O coq-coqide O coq-doc O coq-emacs O coq-emacs-el O cryptominisat O cryptominisat-devel O csisat O cudd O cvc3 O cvc3-devel O cvc3-doc O cvc3-emacs O cvc3-emacs-el O cvc3-java O cvc3-xemacs O cvc3-xemacs-el O E O emacs-common-proofgeneral O emacs-proofgeneral O emacs-proofgeneral-el O flocq O flocq-source D frama-c O gappa O gappalib-coq O glueminisat D minisat2 O picosat D prover9 O prover9-apps O prover9-devel O prover9-doc O pvs-sbcl O sat4j O stp O stp-devel O tex-zfuzz O why O why-all O why-coq O why-gwhy O why-jessie O why-pvs-support O why3 O why3-emacs O zenon More information on these packages can be found on the wiki here: https://fedoraproject.org/wiki/Formal_methods_tool_suite https://fedoraproject.org/wiki/FormalMethods Regards, John -- John C. Peterson, KD6EKQ mailto:j...@eskimo.com San Diego, CA U.S.A -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 16 August 2013 19:41, "Jóhann B. Guðmundsson" wrote: > On 08/15/2013 03:55 PM, Stephen John Smoogen wrote: > > What's alarming with the decision to officially support upgrades that it > was done without consulting the QA community, which are the ones that have > to come up with the test cases,make the necessary changes to the release > criteria, essentially have to do all the work and above all test it. > > I am going to have to reverse the question. While I was helping out when I could from Red Hat 7 -> Fedora 7, QA always tested upgrades. The basic tests were: 1) Install last release, test an upgrade from that to latest. Report what broke. 2) Install release-2, test an upgrade from that to latest. Report what broke. 3) Install last release, rpm -Uvh (before yum and yum update afterwords), test an upgrade to latest. See what broke. 4) Install release-2 If the install was "important" for some reason (in the RHL days that would have been something like RHL-5.2, RHL-6.2, RHL-7.3 and before core went away Fedora Core 6). you would do a chain upgrade (RHL-2.1 -> whatever now is.) and document what was broken. So sometime after Fedora 7. Support of upgrades was basically that we knew it worked if you did this and it might work if you did that, and it probably won't work outside of that. So my guess is that sometime after F7 (maybe when upgrade was no longer a path in Anaconda?) it was considered not supported anymore? -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Sat, Aug 17, 2013 at 11:12 PM, Stephen John Smoogen wrote: > So my guess is that sometime after F7 (maybe when upgrade was no longer a > path in Anaconda?) it was considered not supported anymore? No and anaconda lost support in F18 (and fedup took its place). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Java package] add_to_maven_depmap macro issue
Hi, One of my packages: dcm4che-test fails to build for rawhide currently. There's a bug filed here[1]. The build.log seems to fail on the "add_to_maven_depmap" macro. I think it doesn't find it at all[2]. Could someone please tell me if I'm missing a BR or if the macros have changed[3]? [1] https://bugzilla.redhat.com/show_bug.cgi?id=992114 [2] http://ankursinha.fedorapeople.org/dcm4che-build.log [3] http://fedoraproject.org/wiki/Java/JPPMavenReadme#Packages_adding_their_own_depmaps -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
