Re: Package maintainers -- want test results by mail?
On Thursday 03 June 2010, Adam Williamson wrote: > On Wed, 2010-06-02 at 23:05 +0100, Mat Booth wrote: > > It doesn't even know all English words. In one review I did recently > > rpmlint flagged the word "decryption" as a spelling error. Which I > > didn't believe, so I looked it up. It's a valid noun form of the verb > > "decrypt" in the English dictionary I have here... > > OED agrees, 'decryption' is listed as a valid form under its entry for > decrypt. rpmlint uses python-enchant, and enchant in Fedora is configured to use myspell for English by default [0]. myspell means that enchant actually uses hunspell in Fedora under the hood, and thus the place to fix dictionary omissions/bugs for English for all software that ends up using hunspell (directly or via enchant), not only rpmlint, is currently the hunspell-en package. $ echo decryption | hunspell -d en_US Hunspell 1.2.8 & decryption 4 0: encryption, deception, description, decoration [0] /usr/share/enchant/enchant.ordering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On 06/02/2010 08:23 PM, seth vidal wrote: > On Wed, 2010-06-02 at 10:46 -0700, Jesse Keating wrote: >> On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: >>> And I doubt that python scripts in below >>> /usr/lib/python2.6/site-packages usually need to be executable. Since >>> yum works without any problems, these tons of errors are useless, too. >>> And they make it only harder to find real errors. I did not think more >>> about the other quoted rpmlint messages. >>> >>> >> >> It's complaining because the files have #! in them, likely to assist in >> self tests, but the files aren't marked as executable. That could >> actually be fixed upstream, either mark them as executable or remove the >> #!s. >> > > I've considered removing them in upstream just to shut rpmlint up. > > As irritating as that is. !!! rpmlint is warning about details which don't cause malfunctions or are harmful. This behavior is useful when being used as an interactive aid to assist a packager/reviewer. But I don't consider this behavior to be useful when rpmlint is being used as part of an automated QA process. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On 06/02/2010 11:11 PM, Toshio Kuratomi wrote: = > If someone would let the FPC know how to write good upstart scripts and > packages we could certainly write up minimum requirements for the case where > someone does want to package an upstart script. And systemd is coming soon too ... i think it would be healthy to let folks try these out and decide for themselves which should be our default in fedora ... systemd sounds good ... gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On 06/02/2010 07:25 PM, Matt McCutchen wrote: > On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: >> Well, then lets begin: >> >> # rpmlint yum >> yum.noarch: W: self-obsoletion yum-allow-downgrade< 1.1.20-0 obsoletes >> yum-allow-downgrade > [...] >> yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash >> yum.noarch: E: non-executable-script >> /usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python > > [...] >> Or ... >> # rpmlint binutils >> binutils.x86_64: W: spelling-error %description -l en_US addr -> add, >> adder, adds >> binutils.x86_64: W: shared-lib-calls-exit >> /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so e...@glibc_2.2.5 >> binutils.x86_64: W: shared-lib-calls-exit >> /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so _e...@glibc_2.2.5 >> binutils.x86_64: W: unused-direct-shlib-dependency >> /usr/lib64/libopcodes-2.20.51.0.2-20.fc13.so /lib64/libz.so.1 >> binutils.x86_64: W: no-manual-page-for-binary ld.bfd >> binutils.x86_64: W: no-manual-page-for-binary ld.gold >> binutils.x86_64: W: dangerous-command-in-%post rm >> 1 packages and 0 specfiles checked; 0 errors, 7 warnings. > > Which of those messages do you consider noise and why? All of them. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Curiosity, Are Cursor Themes that Critical?
On 06/03/2010 08:44 AM, Matthias Clasen wrote: > The complication was the talk about virtual provides and whatnot. > If the desktop doesn't fall apart if I fail to install a cursor theme (it should be able to cope up really), all that is needed is for you to drop the explicit dependency and add it to comps as a default package and be done with it. No virtual provides. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On 06/03/2010 01:32 AM, Jon Masters wrote: > Yea. I think you don't do updates for it in general. I think I agree > with Seth that this is something Anaconda stuffs in place when it > installs grub. > I think a RFE has been filed against Anaconda before but please file one if not. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: deluge and flags sub package
On 06/03/2010 02:40 AM, Peter Gordon wrote: > On Wed, 2010-06-02 at 00:56 +0530, Rahul Sundaram wrote: > >> I will work with Ankur Sinha and probably do this for Rawhide in the >> next couple of days. Peter Gordon, let me know if you have any objections >> > This sounds good to me - please go ahead with your changes. > > (Apologies about the unavailability over the past several weeks. Final > projects and trips with family/friends have consumed most of my time. > I'm back and ready to rock some Fedora packages, though! ^_~) > Ah, I was hoping you would show up. Can you take a look at https://admin.fedoraproject.org/updates/deluge-1.2.3-2.fc13,rb_libtorrent-0.14.10-3.fc13 I want to make sure I didn't muck up anything. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Curiosity, Are Cursor Themes that Critical?
On Thu, 2010-06-03 at 08:35 +0530, Rahul Sundaram wrote: > On 06/03/2010 03:28 AM, Matthias Clasen wrote: > > > > That is just making things complicated, for minimal gain. > > > > > > Yes and no. Purely as a desktop user, there isn't much of a gain but > certainly for a more minimalistic environment it makes sense to list > them in comps and not add a artificial dependency. It also helps Fedora > Remixes switch defaults with minimal amount of effort. I think leaving > things customizable is a benefit. I don't see much of a complication > really. The complication was the talk about virtual provides and whatnot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Thu, Jun 03, 2010 at 10:18:59AM +0800, Chen Lei wrote: > 2010/6/3 Toshio Kuratomi : > >> > > This is intended to tell people that SystemVinit scripts are mandatory for > > services managed by the init system. But providing native upstart as an > > addition (or initng, minit, etc) is not prohibited by this. > > > > -Toshio > > > > > I don't think provide both upstart and initscript for one package will > benefic fedora, especially in the scenario when the upstart scripts > have seriously functional regression compared with initscripts. > Currently, only one packager provide both upstart scripts and > initscripts. > > We currently don't have a policy about upstart scripts, however a > single person to change his packaging style agaist all other packagers > in the repo will confuse many linux users or system administators. > > Before opposing me, you can look at those -upstart subpackages, you'll > found they are not as good as you imagined. They are different from > other system upstart scripts. > I'm not going to oppose you on the ground that enrico has written good packages; I'll oppose you on the groupnd that it's not the job of Fedora to prevent people from providing functionality above the minimum. If someone would let the FPC know how to write good upstart scripts and packages we could certainly write up minimum requirements for the case where someone does want to package an upstart script. -Toshio pgpivfApqoHVt.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Curiosity, Are Cursor Themes that Critical?
On 06/03/2010 03:28 AM, Matthias Clasen wrote: > > That is just making things complicated, for minimal gain. > > Yes and no. Purely as a desktop user, there isn't much of a gain but certainly for a more minimalistic environment it makes sense to list them in comps and not add a artificial dependency. It also helps Fedora Remixes switch defaults with minimal amount of effort. I think leaving things customizable is a benefit. I don't see much of a complication really. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
2010/6/3 Toshio Kuratomi : >> > This is intended to tell people that SystemVinit scripts are mandatory for > services managed by the init system. But providing native upstart as an > addition (or initng, minit, etc) is not prohibited by this. > > -Toshio > > I don't think provide both upstart and initscript for one package will benefic fedora, especially in the scenario when the upstart scripts have seriously functional regression compared with initscripts. Currently, only one packager provide both upstart scripts and initscripts. We currently don't have a policy about upstart scripts, however a single person to change his packaging style agaist all other packagers in the repo will confuse many linux users or system administators. Before opposing me, you can look at those -upstart subpackages, you'll found they are not as good as you imagined. They are different from other system upstart scripts. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, Jun 2, 2010 at 3:45 PM, Adam Williamson wrote: > It's a bit intangible and not entirely predicated on whether we're using > the keyword or flag setup, I think. Currently when we're considering > bugs we use a search that excludes closed bugs, In either case, I would suggest that it may be best to just exclude certain closed resolutions but review others. wontfix and notabug may hide some potential blockers that are worthy of calm discussion with a maintainer from a release management pov. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, 2010-06-02 at 15:31 -0800, Jeff Spaleta wrote: > On Wed, Jun 2, 2010 at 2:07 PM, Adam Williamson wrote: > > Ah. It's a shame it wasn't put up for consideration as a release > > blocker. Obviously the rather peremptory response from Jakub didn't help > > with that... > > Would the flag concept for blocker status that Jesse was championing > recently have helped in this situation. If the bug is closed with a > non fixed resolution, but flagged with request from the reporter to be > a blocker would this have provided a mechanism to escalate this issue > into a release management discussion that would have revisited the > issue and overturned Jakub's assessment of the situation? Or would > resolution as notabug have nullified a blocker request flag mechanism? It's a bit intangible and not entirely predicated on whether we're using the keyword or flag setup, I think. Currently when we're considering bugs we use a search that excludes closed bugs, so even if you flag a closed bug with F14Blocker or whatever, it won't get on the agenda for the review meeting unless someone explicitly mentions it. I'm not sure Jesse's proposed system necessarily makes any difference to that; even if we're using flags, I don't think we'd automatically start doing searches that included closed bugs. But of course, it might make sense not to worry about the bug status with the more fine-grained info the flag system would provide. Now I've waffled a bit =) I think the ultimate answer is that it's certainly _possible_ we could use the proposed flag system to consider blocker status even for closed bugs, yeah. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, Jun 2, 2010 at 2:07 PM, Adam Williamson wrote: > Ah. It's a shame it wasn't put up for consideration as a release > blocker. Obviously the rather peremptory response from Jakub didn't help > with that... Would the flag concept for blocker status that Jesse was championing recently have helped in this situation. If the bug is closed with a non fixed resolution, but flagged with request from the reporter to be a blocker would this have provided a mechanism to escalate this issue into a release management discussion that would have revisited the issue and overturned Jakub's assessment of the situation? Or would resolution as notabug have nullified a blocker request flag mechanism? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
Elio Maldonado (emald...@redhat.com) said: > > 2) Wait for either of https://admin.fedoraproject.org/updates/glibc-2.12-2 > > or > > https://admin.fedoraproject.org/updates/pidgin-2.7.1-2.fc13 to be pushed to > > stable, as those will pull in the i686 nss-softokn-freebl through library > > dependencies. > > Thank you Bill. Further research shows that the pidgin update will *not* help this particular situation, as pidgin/libpurple 2.7.x has dropped its dependency on nss-softokn-freebl. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 23:15 +0300, Ville Skyttä wrote: > On Wednesday 02 June 2010, James Antill wrote: > > > The self obsolete ones are wrong, being able to do: > > > > Name: foo > > Provide: bar = 2 > > Obsolete: bar <= 2 > > > > ...is completely legal and needed for rename/merging > > Yes (assuming you mean "Obsoletes: bar < 2", not "<= 2"). No, I didn't. Obsoletes only work on package names, not on provides so it doesn't matter that the provide and obsolete overlap. > Self-obsoletion used to cause problems in various tools in the past. I don't > know if all of them contain workarounds nowadays, but on the other hand I > don't think I've ever seen an actual valid use case for self-obsoletion. Yeh, I looked at the bug but I'm not sure what it is for. If anything it's probably a yum bug but the only one I know about is: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=568eaf5b88f376a1822396fd9dc7324d1aed23ea ...which was a while ago, and didn't cause much damage. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 23:05 +0100, Mat Booth wrote: > It doesn't even know all English words. In one review I did recently > rpmlint flagged the word "decryption" as a spelling error. Which I > didn't believe, so I looked it up. It's a valid noun form of the verb > "decrypt" in the English dictionary I have here... OED agrees, 'decryption' is listed as a valid form under its entry for decrypt. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, 2010-06-02 at 23:54 +0200, Till Maas wrote: > On Wed, Jun 02, 2010 at 02:43:11PM -0700, Adam Williamson wrote: > > On Wed, 2010-06-02 at 09:13 -0500, Bruno Wolff III wrote: > > > > > This issue points out a gap in our QA testing. > > > > Indeed, although there are _many_ gaps in our QA testing, and this is > > not news. =) We don't have the resources to test anywhere close to > > everything. The extent of claimed CPU arch support is just one of the > > things we're not equipped to test... > > > > (It does kind of surprise me that _no-one_ at OLPC managed to notice > > this before release, though. We do betas!) > > The bug report was there one week before the announcement of the beta: > https://bugzilla.redhat.com/show_bug.cgi?id=579838 Ah. It's a shame it wasn't put up for consideration as a release blocker. Obviously the rather peremptory response from Jakub didn't help with that... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 23:51 +0200, Alexander Boström wrote: > Ok, a mini-Fedora that lives entirely in a subdir of the boot partition, > containing an application for managing grub.conf and other things. > Things it should be able to do: > > * Manage those yum-integrated btrfs snapshots. > * Download Fedora and other distro pxeboot and live images and > stick them in grub.conf. > * Change default boot menu entry, edit entries etc. > > Plus a terminal and various tools. If we do this, the default /boot size should certainly be increased by an amount equal to the size of image. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On 2 June 2010 22:33, Adam Williamson wrote: > On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote: > > On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote: > > > On 06/01/2010 10:43 PM, James Laska wrote: > > > > Greetings package maintainers, > > > > > > > > Want to get notification of any breakage in your just-built koji > > > > packages? This includes results of rpmlint [1], > > > > > > Unless rpmlint starts to use a massively cleaned up set of rules, its > > > results are mostly noise. > > > > Which packages do you maintain where the output has become unmanageable? > > One thing I'd dearly like to see suppressed in most cases is the spell > checking. Most package descriptions need to use jargon which spell > checkers just don't recognize. I just ran some random rpmlints to check > how it's behaving these days, and here's my collection of 'spelling > error' warnings: > > libdrm > sK > gpsd > pre > > aside from this most of the output I get is pretty sane, though. > It doesn't even know all English words. In one review I did recently rpmlint flagged the word "decryption" as a spelling error. Which I didn't believe, so I looked it up. It's a valid noun form of the verb "decrypt" in the English dictionary I have here... -- Mat Booth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 16:55 -0400, Jon Masters wrote: > On Wed, 2010-06-02 at 16:47 -0400, Przemek Klosowski wrote: > > On 06/02/2010 04:02 PM, Jon Masters wrote: > > > > > That said, of course eventually you could have two of these images and > > > allow for them to be upgraded, etc. etc. To start with though, I think > > > there's a lot of value in pre-committing a couple hundred MB of disk > > > space to having a rescue environment always on. > > > > Rescue environment aside, it'd be nice to avoid failing the upgrade > > because of insufficient space in /boot. I think 200 MB default /boot > > prove to be too small---perhaps 500 MB should be the new default? > > It does seem to be the default in RHEL now, and makes sense. Still, > that's a separate topic for another thread I think (/boot). Well, to close the topic off, 500MB is also default for F13 onwards. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Curiosity, Are Cursor Themes that Critical?
On Wed, 2010-06-02 at 14:28 -0700, Adam Williamson wrote: > On Wed, 2010-06-02 at 11:50 -0600, Geoff Reedy wrote: > > On Wed, Jun 02, 2010 at 02:42:08AM +0530, Rahul Sundaram said > > > The former is the default theme and has been added as a dependency to a > > > core package. You are seeing a cascading set of dependencies as a result. > > > > Should that be done through comps? It's not a really required for > > functionality of those packages since there's always the possiblity to > > fall back to the old builtin bitmap cursors right? > > Right, I was about to say the same things. If there's not actually a > hard dependency here - if no cursor theme package needs to be installed > for the desktop to run - there should be no dependency, and the dmz > theme should simply be listed in comps. If the dependency is just that > *some* cursor theme needs to be installed, all cursor themes should > provide something like 'cursor-theme' and the dependency should be on > this virtual provide, not on any specific theme. That is just making things complicated, for minimal gain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, Jun 02, 2010 at 02:43:11PM -0700, Adam Williamson wrote: > On Wed, 2010-06-02 at 09:13 -0500, Bruno Wolff III wrote: > > > This issue points out a gap in our QA testing. > > Indeed, although there are _many_ gaps in our QA testing, and this is > not news. =) We don't have the resources to test anywhere close to > everything. The extent of claimed CPU arch support is just one of the > things we're not equipped to test... > > (It does kind of surprise me that _no-one_ at OLPC managed to notice > this before release, though. We do betas!) The bug report was there one week before the announcement of the beta: https://bugzilla.redhat.com/show_bug.cgi?id=579838 Regards Till pgp8Bqijkvw0r.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: about php-qa, phpUnderControl and meta packages
On Wed, 2010-06-02 at 18:31 +0200, Christof Damian wrote: > I am reposting this from fedora php-devel list to get a bigger > audience. My questions are not that PHP specific: Good, because neither are my answers =) I know nothing about the area in question, so bear that in mind. > I got two questions regarding my effort to package more of the php-qa > packages for fedora. > > I have made a package for phpUnderControl now, but to use it you still > have to install CruiseControl by hand. The obvious response here is 'so, package CruiseControl too!' If you can't package CruiseControl, then you shouldn't package phpUnderControl; it's frowned upon / not allowed (I can never remember which) to package something which requires something that can't go into Fedora for some reason. > phpUnderControl also patches > the CruisceControl installation, so it isn't something that can easily > packaged as an RPM. The first obvious response here is 'ew, why does it do that?' The second is 'then package the modified CruiseControl that phpUnderControl requires under a different name, to make it clear it's been modified'. > Does it still make sense to bring phpUnderControl into Fedora even > though it requires an external software package? In general, no - see above. Fedora should be internally complete. But again, the obvious response is 'so, package CruiseControl'. > Second question: I would love to have a meta package which brings all > of these packages ( phpunit, phpmd, phpcpd, phpdoc, phpcs, Mockery, > ...) together and allows installation with one yum command. But as far > as I could detect from the random posts it seems that meta packages > are not really wanted on Fedora. An alternative is the comps list, but > that doesn't allow for rapid changes and phpqa would be a bit > specific. For whatever reason, We Don't Like Metapackages and the 'recommended' way to do it is with a package group. I've never seen a particularly coherent reason given for this, but never mind. Some packagers _have_ done metapackages, and none of them have been shot yet. Just sayin'. > A third option would be to make something like phpUnderControl require > all of these. The pear package already suggests some of them, but it > isn't a hard require. Generally speaking, requirements should be *requirements*; you should only have your phpUC package require those other things if it just wouldn't work without them, or if no sane person would ever actually want to run it without them. Soft dependencies (suggests) are the 'obvious' solution there, but whenever anyone suggests soft dependencies, Seth posts his handy laundry list of corner cases and says 'sure, we'll do it as soon as you can come up with the right way to do all of these', and no-one ever *can* come up with a right way to do them. So we don't get soft deps. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Ok, a mini-Fedora that lives entirely in a subdir of the boot partition, containing an application for managing grub.conf and other things. Things it should be able to do: * Manage those yum-integrated btrfs snapshots. * Download Fedora and other distro pxeboot and live images and stick them in grub.conf. * Change default boot menu entry, edit entries etc. Plus a terminal and various tools. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On 02/06/10 21:55, Jon Masters wrote: --snip-- >> Rescue environment aside, it'd be nice to avoid failing the upgrade >> because of insufficient space in /boot. I think 200 MB default /boot >> prove to be too small---perhaps 500 MB should be the new default? > > It does seem to be the default in RHEL now, and makes sense. Still, > that's a separate topic for another thread I think (/boot). > > Jon. > > Is not F13 /b00t 500mb, going by the boxes here. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering wrote: > On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote: > > This suggests to me that environment variables isn't the right way to do > > this. Environment variables are good for parameters that should be > > available to many processes. Command line parameters are better when the > > parameter is only meant for one specific process. I can see how looking > > up two environment variables may be a smaller patch than adding a > > parameter to the program's command line parser, but I still think it > > should be done with command line > > parameters. > > This is a valid point and we have pondered this for a while and in the > end decided to use environ[] instead of argv[], simply because this > allows us to use the same code for handling it in all daemons, while > handling --listen-fds=xxx in argv would work for some daemons, but not > for others. (i.e. some don't do long getopt, others do it with one dash > only). To handle different command line syntaxes I would apply some simple macro substitution to the command line in the .service file, replacing for example the string "%listen_FDs%" (or some other syntax) with the number of sockets. One daemon could then have the parameter "--listen-fds=%listen_FDs%", another could have "-sockets=%listen_FDs%" and a third could have "-q %listen_FDs%". > Also, quite a few projects (rsyslog for example) implement socket > handling in loadable modules, where we have no access to argv[] but do > have access to environ[]. I'd be surprised if any of those programs are designed such that they have no way of passing parameters to their modules. > > LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the > > original daemon is restarted but its children live on, then later some > > descendant process may get the same PID as the original daemon, and may > > try to handle LISTEN_FDS. The risk may be low, but I always prefer a > > solution that is guaranteed to work over one that mostly works. > > Well, this is purely theoretical, since LISTEN_FDS should normally only > be set for daemons that can actually handle this and hence as long as > these are running none of their children can get the same PID. I'm afraid I don't understand what you mean with "handle this". I thought at first that you meant that LISTEN_FDS should only be used for daemons that are known to clear it, but if that were the case you wouldn't have invented LISTEN_PID. Do you perchance mean that LISTEN_FDS should only be used in cases where all child processes will be killed if the daemon dies? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, 2010-06-02 at 09:13 -0500, Bruno Wolff III wrote: > This issue points out a gap in our QA testing. Indeed, although there are _many_ gaps in our QA testing, and this is not news. =) We don't have the resources to test anywhere close to everything. The extent of claimed CPU arch support is just one of the things we're not equipped to test... (It does kind of surprise me that _no-one_ at OLPC managed to notice this before release, though. We do betas!) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote: > On Wed, 2010-06-02 at 10:49 +0200, Ralf Corsepius wrote: > > On 06/01/2010 10:43 PM, James Laska wrote: > > > Greetings package maintainers, > > > > > > Want to get notification of any breakage in your just-built koji > > > packages? This includes results of rpmlint [1], > > > > Unless rpmlint starts to use a massively cleaned up set of rules, its > > results are mostly noise. > > Which packages do you maintain where the output has become unmanageable? One thing I'd dearly like to see suppressed in most cases is the spell checking. Most package descriptions need to use jargon which spell checkers just don't recognize. I just ran some random rpmlints to check how it's behaving these days, and here's my collection of 'spelling error' warnings: libdrm sK gpsd pre aside from this most of the output I get is pretty sane, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 598989] [abrt] crash in perl-Padre-0.50-4.fc13: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=598989 --- Comment #3 from Petr Pisar 2010-06-02 17:30:50 EDT --- It segfaulted here: 0x003deb46b954 <+36>: callq 0x3deb41c658 => 0x003deb46b959 <+41>: mov0x440(%rax),%rsi That means the gtk2 library tried to dereference return code of g_type_check_instance_c...@plt function at offset 0x440. And because rax was zero, the effective read address was 0x440. According memory mapping list, zeroth page was unmapped. Thus it's simple NULL pointer dereference in libgtk2++. I will check _gdk_x11_screen_process_owner_change() code in gdkscreen-x11.c later. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Curiosity, Are Cursor Themes that Critical?
On Wed, 2010-06-02 at 11:50 -0600, Geoff Reedy wrote: > On Wed, Jun 02, 2010 at 02:42:08AM +0530, Rahul Sundaram said > > The former is the default theme and has been added as a dependency to a > > core package. You are seeing a cascading set of dependencies as a result. > > Should that be done through comps? It's not a really required for > functionality of those packages since there's always the possiblity to > fall back to the old builtin bitmap cursors right? Right, I was about to say the same things. If there's not actually a hard dependency here - if no cursor theme package needs to be installed for the desktop to run - there should be no dependency, and the dmz theme should simply be listed in comps. If the dependency is just that *some* cursor theme needs to be installed, all cursor themes should provide something like 'cursor-theme' and the dependency should be on this virtual provide, not on any specific theme. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 16:04 -0500, Michael Cronenworth wrote: > Eric Sandeen wrote: > > Is it better to have a separate volume for this, or to just have a sort > > of rescue initramfs ...? > > > > Seems like the latter is more flexible but then I'm no boot process wizard. > > Good suggestion. > > Another one: What about LVM snapshots? and/or btrfs snapshots? This is already done. But it's very coarse. You get to unwind (possibly) a lot of stuff, and may not reboot the moment you finish the update. You also need to have /home on a separate volume, etc. etc. It's great, but it's not always what you need. So my suggestion is tangential to that. > Either way would be less wasteful than a whole partition that would be > obsolete in a few weeks and may or may not have to deal with byte > growing pains if the initial size is too small years down the road. An initramfs is fine. I wasn't literally saying the only option was to keep a spare physical partition around. I was thinking that, if it were a volume, it would be an LVM volume that could be resized later. But I think the easiest option for now is simply a rescue initramfs on the /boot volume, and I suppose I see the point now about making a bigger /boot volume if this happens. That does make sense. This would be something you could choose not to have installed anyway IMO. > Another scenario: Your Fedora 14 rescue boot partition was built against > kernel 2.6.34, but the root file system of your Fedora 18 installation > is of a new experimental file system only found in kernel 2.6.38. The > rescue partition is wasted space at this point. When are we going to have a situation in which Fedora ships F14 with a new filesystem that works with Anaconda (and therefore a rescue image) to get installed, but doesn't work after the fact? Maybe you copied and created this by hand, but in that case you get to keep both pieces when it breaks. I'm talking about out-of-the box regular user issues :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
On 06/02/2010 12:51 PM, Bill Nottingham wrote:
> Robert Relyea (rrel...@redhat.com) said:
>>> It's due to the fact that nss-softokn-freebl (actually, *all* the nss/nspr
>>> libraires) do not fit the normal library naming, so it's not explicitly
>>> pulled for
>>> multilib. For any update or release set that's composed with a package that
>>> explicitly
>>> requires a compat arch of nss-softokn-freebl (such as glibc, libpurple,
>>> pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13
>>> updates has none of these, so it doesn't.
>>>
>>> We could add some hacks to mash to get it pulled in, but I must ask...
>>> why do all the NSS/NSPR libraries version their libraries in the library
>>> name instead of the so version (i.e., libfreebl3.so instead of
>>> libfreebl.so.3)?
>>>
>> Because upstream selected it's names before linux naming was anything
>> like widespread.
>>
>> nss/nspr upstream was also unusual in considering binary compatibility
>> breakage a sev 1 bug. It's expected that old apps run against new versions.
>>
>> One good side effect of this is there is no name colision in the
>> libraries between Network Security Services and Name Switch Select, nor
>> NSS's libssl3.so and openssl's libssl.so.
>
> OK. Copying from the bug:
>
> There are two 'simple' fixes for this that don't involve hotfixing the push
> infrastructure:
>
> 1) For all nss/nspr packages that don't have .so symlinks in their devel
> packages, add %{?_isa} to the requires in the devel packages.
>
> See https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires for
> a packaging draft for this.
>
> For example, that would change, in nss-softokn-freebl-devel:
>
> Requires: nss-softokn-freebl = %{version}-%{release}
> to:
> Requires: nss-softokn-freebl%{?_isa} = %{version}-%{release}
>
> in nss-softokn-freebl-devel,
>
> Requires: nss-softokn = %{version}-%{release}
> to
> Requires: nss-softokn%{?_isa} = %{version}-%{release}
>
> in nss-softokn-devel, and so on.
>
> The reason this is needed is that for most -devel pacakges, there is automatic
> dependencies added on the proper library package due to following the '.so'
> devel symlink to the main library. This doesn't work for nss/nspr, as the
> -devel packages don't have these symlinks.
>
> 2) Wait for either of https://admin.fedoraproject.org/updates/glibc-2.12-2 or
> https://admin.fedoraproject.org/updates/pidgin-2.7.1-2.fc13 to be pushed to
> stable, as those will pull in the i686 nss-softokn-freebl through library
> dependencies.
Thank you Bill.
Elio
>
> Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: deluge and flags sub package
On Wed, 2010-06-02 at 00:56 +0530, Rahul Sundaram wrote: > I will work with Ankur Sinha and probably do this for Rawhide in the > next couple of days. Peter Gordon, let me know if you have any objections This sounds good to me - please go ahead with your changes. (Apologies about the unavailability over the past several weeks. Final projects and trips with family/friends have consumed most of my time. I'm back and ready to rock some Fedora packages, though! ^_~) -- Peter Gordon (codergeek42) Who am I? :: http://thecodergeek.com/about-me signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Thu, Jun 03, 2010 at 02:30:23AM +0800, Chen Lei wrote: > 2010/6/3 Matt McCutchen : > > On Wed, 2010-06-02 at 20:00 +0200, Kevin Kofler wrote: > >> Chen Lei wrote: > >> > Is it right for the maintainer to provide two separate subpackages, > >> > one with the tranditional rc.d contents and one with an upstart > >> > scripts and make the -upstart subpackage have a higher priority over > >> > sysinit subpackage? > >> > >> No. This is against our packaging guidelines. > > > > Where do you see that? > > > > -- > > Matt > > > I'm not sure about whether ship upstart scripts violate our > guidelines, but fedora package guideline has - "Currently, only > SystemV-style initscripts are supported in Fedora". > hshiottp://fedoraproject.org/wiki/PackagingGuidelines#Initscripts > This is intended to tell people that SystemVinit scripts are mandatory for services managed by the init system. But providing native upstart as an addition (or initng, minit, etc) is not prohibited by this. -Toshio pgpOKc163P3Oa.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Eric Sandeen wrote: > Is it better to have a separate volume for this, or to just have a sort > of rescue initramfs ...? > > Seems like the latter is more flexible but then I'm no boot process wizard. Good suggestion. Another one: What about LVM snapshots? and/or btrfs snapshots? Either way would be less wasteful than a whole partition that would be obsolete in a few weeks and may or may not have to deal with byte growing pains if the initial size is too small years down the road. Another scenario: Your Fedora 14 rescue boot partition was built against kernel 2.6.34, but the root file system of your Fedora 18 installation is of a new experimental file system only found in kernel 2.6.38. The rescue partition is wasted space at this point. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 02, 2010 at 01:43:10PM -0500, Michael Cronenworth wrote: > Lennart Poettering wrote: > > We wanted to make the transition from sysv to systemd very easy, and I > > think this is the simplemost scheme we could come up with. During a > > transition period packages should just ship both files and it'll work > > with both init systems. > > s/systemd/upstart/ > This is not the first time this has been said. > > Even though there may not be an initiative to switch from sysv to > upstart, why do you feel so strongly that people will switch from sysv > to systemd? Are you going to implement a Fedora policy that bans sysv, > say, in Fedora 16? That's about the only way you could make it happen. > Well one of the reasons that we are still using sysvinit compatibility for upstart is that people have been actively told not to switch to native upstart scripts. So our current situation is not really an indicator of what to expect with a new init system where we actively tell people to switch. -Toshio pgpHxgmAx0npU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 16:47 -0400, Przemek Klosowski wrote: > On 06/02/2010 04:02 PM, Jon Masters wrote: > > > That said, of course eventually you could have two of these images and > > allow for them to be upgraded, etc. etc. To start with though, I think > > there's a lot of value in pre-committing a couple hundred MB of disk > > space to having a rescue environment always on. > > Rescue environment aside, it'd be nice to avoid failing the upgrade > because of insufficient space in /boot. I think 200 MB default /boot > prove to be too small---perhaps 500 MB should be the new default? It does seem to be the default in RHEL now, and makes sense. Still, that's a separate topic for another thread I think (/boot). Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 15:39 -0500, Eric Sandeen wrote: > The ability to create/update a rescue image would be very useful IMHO. If it was a ramfs that was writable, and you had say yum/rpm in there, you could update the running code and make use of a newer e2fsck... -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 15:39 -0500, Eric Sandeen wrote: > Jon Masters wrote: > > On Wed, 2010-06-02 at 21:22 +0100, Richard W.M. Jones wrote: > >> On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote: > > > >>> Is it better to have a separate volume for this, or to just have a sort > >>> of rescue initramfs ...? > >> Or if you are able to run a little bit of C code[1] and can read files > >> from the root partition (as grub can), you can build one on the fly > >> using binaries, libraries etc found on the root disk, which is what we > >> do in libguestfs. > > > > I specifically think this is not the solution :) It's great for > > libguestfs, but the idea here is to have known-good binaries that can be > > used to recover a system - and that change very rarely indeed (on the > > same order as the "physical" media containing the installer) - when it > > is broken during an update or otherwise. If the system is already > > busticated, then building images from it will not help. > > Totally depends on how it got busted. Yea, but why rebuild it unless you need to? I'm talking about being able to boot into a rescue environment. I don't really care which version of KDE/GNOME is available, only that some major change to Fedora is picked up in time. For example if this was around the time LUKS support was added, it would be useful to have that, but then such a major item would line up with a new Fedora release anyway and have Anaconda dependencies. I know Fedora is all about fast pace, but this is one time where it's a good idea not to move quickly :) And frankly, even Windows has a "Safe Mode" that often works to boot into a recovery environment. > > A recovery initramfs could be used. It could just basically be the > > rescue mode anaconda bits in one image shoved in place to start. > > This makes sense to me as a pretty simple solution to get going with. Ok. When I get a minute, I'll write this up and suggest that as a starting point to get something vaguely useful. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On 06/02/2010 04:02 PM, Jon Masters wrote: > That said, of course eventually you could have two of these images and > allow for them to be upgraded, etc. etc. To start with though, I think > there's a lot of value in pre-committing a couple hundred MB of disk > space to having a rescue environment always on. Rescue environment aside, it'd be nice to avoid failing the upgrade because of insufficient space in /boot. I think 200 MB default /boot prove to be too small---perhaps 500 MB should be the new default? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Jon Masters wrote: > On Wed, 2010-06-02 at 21:22 +0100, Richard W.M. Jones wrote: >> On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote: > >>> Is it better to have a separate volume for this, or to just have a sort >>> of rescue initramfs ...? >> Or if you are able to run a little bit of C code[1] and can read files >> from the root partition (as grub can), you can build one on the fly >> using binaries, libraries etc found on the root disk, which is what we >> do in libguestfs. > > I specifically think this is not the solution :) It's great for > libguestfs, but the idea here is to have known-good binaries that can be > used to recover a system - and that change very rarely indeed (on the > same order as the "physical" media containing the installer) - when it > is broken during an update or otherwise. If the system is already > busticated, then building images from it will not help. Totally depends on how it got busted. Certainly you would not want to automatically update the rescue with each new rpm install; that'd be foolish. And I think the converse is very possible - "crap, my root filesystem is corrupted but this old e2fsck won't fix it. I know the fix is in newer packages but it's not in my rescue image! Argh!" Or, maybe you want some new tool that isn't in the default set. The ability to create/update a rescue image would be very useful IMHO. > A recovery initramfs could be used. It could just basically be the > rescue mode anaconda bits in one image shoved in place to start. This makes sense to me as a pretty simple solution to get going with. -Eric > Jon. > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: culmus-fonts packaging bug / Non-responsive maintainer
On Wed, Jun 02, 2010 at 06:49:53PM +0200, Michael Schwendt wrote: > On Thu, 03 Jun 2010 00:07:24 +0900, Mamoru wrote: > > > Toshio Kuratomi wrote, at 06/02/2010 11:51 PM +9:00: > > > On Wed, Jun 02, 2010 at 08:12:08PM +0900, Mamoru Tasaka wrote: > > >> Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00: > > >>> http://bugzilla.redhat.com/570819 > > >>> > > Most simple test-case: > > 1) use Fedora 13 > 2) yum -y install yum-utils > 3) repoclosure -n > Thanks! patch for yum attached to the bug. -Toshio pgpMl4BxPR088.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 21:22 +0100, Richard W.M. Jones wrote: > On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote: > > Is it better to have a separate volume for this, or to just have a sort > > of rescue initramfs ...? > > Or if you are able to run a little bit of C code[1] and can read files > from the root partition (as grub can), you can build one on the fly > using binaries, libraries etc found on the root disk, which is what we > do in libguestfs. I specifically think this is not the solution :) It's great for libguestfs, but the idea here is to have known-good binaries that can be used to recover a system - and that change very rarely indeed (on the same order as the "physical" media containing the installer) - when it is broken during an update or otherwise. If the system is already busticated, then building images from it will not help. A recovery initramfs could be used. It could just basically be the rescue mode anaconda bits in one image shoved in place to start. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wednesday 02 June 2010, Ralf Corsepius wrote: > binutils.x86_64: W: spelling-error %description -l en_US addr -> add, > adder, adds This is a genuine bug, I'll try to have a look into and/or work around it. Enchant appears to tokenize "addr2line" into two words and naturally ends up flagging the "addr" part as a misspelling. On a quick look the rest of messages you posted seem to be something that should just be fixed in the respective packages, or flag potentially questionable things that packagers should double check, possibly with upstream. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Richard W.M. Jones wrote: > On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote: >> Jon Masters wrote: >>> On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote: > Hm. I can see the use of this, but I can also see issues with how you > do updates for it sanely (if at all.) Why would you do updates for it? Your install CD/DVD to use for rescue boot doesn't get updated. I'd think you'd just install a pristine newer one verbatim if you had a reason to bother, like deciding to burn a new CD. Hence the nice automagic deployment feature would reserve two partitions (or whatevers) for the purpose, so you can install the new image on B and still have the option to boot A if the new one is bad. >>> So I'm willing to help out on this (once RHEL stuff calms down a bit). >>> Do you think it's worth us putting together a wiki feature proposal? >>> >>> Jon. >>> >>> >> Is it better to have a separate volume for this, or to just have a sort >> of rescue initramfs ...? > > Or if you are able to run a little bit of C code[1] and can read files > from the root partition (as grub can), you can build one on the fly > using binaries, libraries etc found on the root disk, which is what we > do in libguestfs. which then solves the "how do I update it?" problem. (of course if you're trying to recover from an update that borked your system, I guess you hope you didn't update the rescue recently!) -Eric > Rich. > > [1] > http://git.annexia.org/?p=febootstrap.git;a=blob;f=febootstrap-supermin-helper.c;hb=HEAD > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, Jun 02, 2010 at 03:13:21PM -0500, Eric Sandeen wrote: > Jon Masters wrote: > > On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote: > >>> Hm. I can see the use of this, but I can also see issues with how you > >>> do updates for it sanely (if at all.) > >> Why would you do updates for it? Your install CD/DVD to use for rescue > >> boot doesn't get updated. I'd think you'd just install a pristine newer > >> one verbatim if you had a reason to bother, like deciding to burn a new CD. > >> Hence the nice automagic deployment feature would reserve two partitions > >> (or whatevers) for the purpose, so you can install the new image on B and > >> still have the option to boot A if the new one is bad. > > > > So I'm willing to help out on this (once RHEL stuff calms down a bit). > > Do you think it's worth us putting together a wiki feature proposal? > > > > Jon. > > > > > > Is it better to have a separate volume for this, or to just have a sort > of rescue initramfs ...? Or if you are able to run a little bit of C code[1] and can read files from the root partition (as grub can), you can build one on the fly using binaries, libraries etc found on the root disk, which is what we do in libguestfs. Rich. [1] http://git.annexia.org/?p=febootstrap.git;a=blob;f=febootstrap-supermin-helper.c;hb=HEAD -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wednesday 02 June 2010, Matt McCutchen wrote: > The right thing to do is to file a bug against bash-completion to get > that decision made and then implement it, either by marking the file as > config or moving /etc/bash_completion.d to /usr/share. The warning is > not wrong. Moving to /usr/share is likely to happen in a not-too-distant-future bash- completion upstream release. /etc/bash_completion.d will however almost certainly be kept around for backwards compatibility for some time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wednesday 02 June 2010, James Antill wrote:
> The self obsolete ones are wrong, being able to do:
>
> Name: foo
> Provide: bar = 2
> Obsolete: bar <= 2
>
> ...is completely legal and needed for rename/merging
Yes (assuming you mean "Obsoletes: bar < 2", not "<= 2").
> which is why yum has them.
yum does not have them like that. The Provides in it are unversioned.
Obsoletes: yum-skip-broken <= 1.1.18
Obsoletes: yum-basearchonly <= 1.1.9
Obsoletes: yum-allow-downgrade < 1.1.20-0
Obsoletes: yum-plugin-allow-downgrade < 1.1.22-0
Obsoletes: yum-plugin-protect-packages < 1.1.27-0
Provides: yum-skip-broken
Provides: yum-basearchonly
Provides: yum-allow-downgrade
Provides: yum-plugin-allow-downgrade
Provides: yum-protect-packages
Provides: yum-plugin-protect-packages
Fix: sed -i -e 's/\(Provides.*\)/\1 = %{version}-%{release}/' yum.spec
Self-obsoletion used to cause problems in various tools in the past. I don't
know if all of them contain workarounds nowadays, but on the other hand I
don't think I've ever seen an actual valid use case for self-obsoletion.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Jon Masters wrote: > On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote: >>> Hm. I can see the use of this, but I can also see issues with how you >>> do updates for it sanely (if at all.) >> Why would you do updates for it? Your install CD/DVD to use for rescue >> boot doesn't get updated. I'd think you'd just install a pristine newer >> one verbatim if you had a reason to bother, like deciding to burn a new CD. >> Hence the nice automagic deployment feature would reserve two partitions >> (or whatevers) for the purpose, so you can install the new image on B and >> still have the option to boot A if the new one is bad. > > So I'm willing to help out on this (once RHEL stuff calms down a bit). > Do you think it's worth us putting together a wiki feature proposal? > > Jon. > > Is it better to have a separate volume for this, or to just have a sort of rescue initramfs ...? Seems like the latter is more flexible but then I'm no boot process wizard. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 2, 2010 at 10:43 AM, Michael Cronenworth wrote: > Lennart Poettering wrote: > If you can make everyone move away from sysv to something else, then by > all means I'll do my best to aid in patches, but I don't have much > confidence since everything that has been said about systemd has been > said of upstart a few years ago. Instead of reinventing the wheel time > and time again, there are other features that deserve attention. I think its really premature to talk about any situation where we forcibly drop sysv compatibility. Way way premature. It may never be possible in reality. You'll note that so far we haven't actually encouraged the use of upstart native scripts. It's difficult to see how one could lose confidence based on our upstart experience when the reality is we've barely moved away from sysv. We have just a few native upstart scripts. We've essentially been running upstart in sysv compatibility mode putting nearly zero demands on casual packagers to do anything with regard to making init scripts native. That's actually part of the problem with upstart, its lingered for so long in a sort of compatibility mode that its not clear what the realizable benefits actually are. I don't think I've seen any quantitative analysis of the impact of upstart native configs in any real deployment scenario. This is one of the things I'm looking forward to seeing in future systemd discussion. I fully expect that systemd integration to start in a sysv compatibility mode..but with real native configuration usage up front in enough components for us to work with so we can all get a taste of the impact. I fully anticipate systemd sysv compatibility mode as a priority to make sure no casual maintainer is forced to build native configs out of the gate on their own. i fully expect, and trust, that the people who really grok systemd are going to be heavily involved with ensuring the first set of native systemd services are exemplary examples for the rest of us to follow...and to do our best to break. If the wins are obvious, then work on native configs will snowball based on a desire to maximize the achievable benefits. All Lennart is saying is that systemd will have a better experience for packagers while we are navigating the switch-over period. We won't have to play games with subpackages..we ship both sysv and native systemd in the same package. Eventually Fedora project leadership may decide that native configs will be required for new packages or what not as a policy decision...but that discussion is a long long long way off. Let's just see if we can actually get systemd in early into F14 testing, relying on sysv compatibility primarily so we can feel comfortable that its been well tested. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 13:03 -0700, Roland McGrath wrote: > > Hm. I can see the use of this, but I can also see issues with how you > > do updates for it sanely (if at all.) > > Why would you do updates for it? Your install CD/DVD to use for rescue > boot doesn't get updated. I'd think you'd just install a pristine newer > one verbatim if you had a reason to bother, like deciding to burn a new CD. > Hence the nice automagic deployment feature would reserve two partitions > (or whatevers) for the purpose, so you can install the new image on B and > still have the option to boot A if the new one is bad. So I'm willing to help out on this (once RHEL stuff calms down a bit). Do you think it's worth us putting together a wiki feature proposal? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
> Hm. I can see the use of this, but I can also see issues with how you > do updates for it sanely (if at all.) Why would you do updates for it? Your install CD/DVD to use for rescue boot doesn't get updated. I'd think you'd just install a pristine newer one verbatim if you had a reason to bother, like deciding to burn a new CD. Hence the nice automagic deployment feature would reserve two partitions (or whatevers) for the purpose, so you can install the new image on B and still have the option to boot A if the new one is bad. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 15:54 -0400, Bill Nottingham wrote: > Jon Masters (jonat...@jonmasters.org) said: > > There are various projects implementing LiveCD, rescue, or snapshotted > > updates. I would like to propose a feature in which some of the > > rescue/LiveCD bits are (optionally) installed to a spare volume during > > install such that there's always a rescue/Live boot option that can boot > > up to a recovery desktop without needing to grab media, etc. > > > > Modern disks are large and cheap (even some SSDs). I can't see a > > downside and it helps with all manner of botched updates. Snapshots help > > aswell, but there are many times where you just want something more than > > a single user boot to fix some breakage. > > Hm. I can see the use of this, but I can also see issues with how you > do updates for it sanely (if at all.) Yea. I think you don't do updates for it in general. I think I agree with Seth that this is something Anaconda stuffs in place when it installs grub. Optionally, maybe you upgrade it once per release when you next run Anaconda, but basically it doesn't change. It's about "get me booted to more than a command line to fix stuff", not latest glitz. That said, of course eventually you could have two of these images and allow for them to be upgraded, etc. etc. To start with though, I think there's a lot of value in pre-committing a couple hundred MB of disk space to having a rescue environment always on. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Jon Masters (jonat...@jonmasters.org) said: > There are various projects implementing LiveCD, rescue, or snapshotted > updates. I would like to propose a feature in which some of the > rescue/LiveCD bits are (optionally) installed to a spare volume during > install such that there's always a rescue/Live boot option that can boot > up to a recovery desktop without needing to grab media, etc. > > Modern disks are large and cheap (even some SSDs). I can't see a > downside and it helps with all manner of botched updates. Snapshots help > aswell, but there are many times where you just want something more than > a single user boot to fix some breakage. Hm. I can see the use of this, but I can also see issues with how you do updates for it sanely (if at all.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
Robert Relyea (rrel...@redhat.com) said:
> > It's due to the fact that nss-softokn-freebl (actually, *all* the nss/nspr
> > libraires) do not fit the normal library naming, so it's not explicitly
> > pulled for
> > multilib. For any update or release set that's composed with a package that
> > explicitly
> > requires a compat arch of nss-softokn-freebl (such as glibc, libpurple,
> > pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13
> > updates has none of these, so it doesn't.
> >
> > We could add some hacks to mash to get it pulled in, but I must ask...
> > why do all the NSS/NSPR libraries version their libraries in the library
> > name instead of the so version (i.e., libfreebl3.so instead of
> > libfreebl.so.3)?
> >
> Because upstream selected it's names before linux naming was anything
> like widespread.
>
> nss/nspr upstream was also unusual in considering binary compatibility
> breakage a sev 1 bug. It's expected that old apps run against new versions.
>
> One good side effect of this is there is no name colision in the
> libraries between Network Security Services and Name Switch Select, nor
> NSS's libssl3.so and openssl's libssl.so.
OK. Copying from the bug:
There are two 'simple' fixes for this that don't involve hotfixing the push
infrastructure:
1) For all nss/nspr packages that don't have .so symlinks in their devel
packages, add %{?_isa} to the requires in the devel packages.
See https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires for
a packaging draft for this.
For example, that would change, in nss-softokn-freebl-devel:
Requires: nss-softokn-freebl = %{version}-%{release}
to:
Requires: nss-softokn-freebl%{?_isa} = %{version}-%{release}
in nss-softokn-freebl-devel,
Requires: nss-softokn = %{version}-%{release}
to
Requires: nss-softokn%{?_isa} = %{version}-%{release}
in nss-softokn-devel, and so on.
The reason this is needed is that for most -devel pacakges, there is automatic
dependencies added on the proper library package due to following the '.so'
devel symlink to the main library. This doesn't work for nss/nspr, as the
-devel packages don't have these symlinks.
2) Wait for either of https://admin.fedoraproject.org/updates/glibc-2.12-2 or
https://admin.fedoraproject.org/updates/pidgin-2.7.1-2.fc13 to be pushed to
stable, as those will pull in the i686 nss-softokn-freebl through library
dependencies.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, 02.06.10 15:27, Tom Lane (t...@redhat.com) wrote: > > Michael Cronenworth writes: > > If you can make everyone move away from sysv to something else, then by > > all means I'll do my best to aid in patches, but I don't have much > > confidence since everything that has been said about systemd has been > > said of upstart a few years ago. Instead of reinventing the wheel time > > and time again, there are other features that deserve attention. > > Quite. As a packager looking on from the sidelines, this discussion > leaves me wondering why I should expend my non-copious free time on > implementing upstart^H^H^Hsystemd^H^H^Hmaybe something else next year > init scripts. I'll just stick with the tested sysv ones, thanks. Well, while I do object to this kind of conservative thinking I am actually not opposed to the conclusion. i.e. it's fine if people just ship sysv in most cases. It's fine to have a slow transition. As long as the core packages have native scripts and even socket-based activation we already win a lot. But anyway, we probably should not continue the systemd discussion here, at this time. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
Michael Cronenworth writes: > If you can make everyone move away from sysv to something else, then by > all means I'll do my best to aid in patches, but I don't have much > confidence since everything that has been said about systemd has been > said of upstart a few years ago. Instead of reinventing the wheel time > and time again, there are other features that deserve attention. Quite. As a packager looking on from the sidelines, this discussion leaves me wondering why I should expend my non-copious free time on implementing upstart^H^H^Hsystemd^H^H^Hmaybe something else next year init scripts. I'll just stick with the tested sysv ones, thanks. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, 02.06.10 13:43, Michael Cronenworth (m...@cchtml.com) wrote: > > Lennart Poettering wrote: > > We wanted to make the transition from sysv to systemd very easy, and I > > think this is the simplemost scheme we could come up with. During a > > transition period packages should just ship both files and it'll work > > with both init systems. > > s/systemd/upstart/ > This is not the first time this has been said. You are surprised that I believe in the software I am writing? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
On Wed, 2010-06-02 at 15:04 -0400, Jon Masters wrote: > Folks, > > There are various projects implementing LiveCD, rescue, or snapshotted > updates. I would like to propose a feature in which some of the > rescue/LiveCD bits are (optionally) installed to a spare volume during > install such that there's always a rescue/Live boot option that can boot > up to a recovery desktop without needing to grab media, etc. > > Modern disks are large and cheap (even some SSDs). I can't see a > downside and it helps with all manner of botched updates. Snapshots help > aswell, but there are many times where you just want something more than > a single user boot to fix some breakage. > Maybe this request is better made to anaconda? so it stuffs a rescue image in place when it writes grub to begin with? or do you envision it as a 'rescue image' pkg that is installed in @base or some-such? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
suggestion: rescue boot extension
Folks, There are various projects implementing LiveCD, rescue, or snapshotted updates. I would like to propose a feature in which some of the rescue/LiveCD bits are (optionally) installed to a spare volume during install such that there's always a rescue/Live boot option that can boot up to a recovery desktop without needing to grab media, etc. Modern disks are large and cheap (even some SSDs). I can't see a downside and it helps with all manner of botched updates. Snapshots help aswell, but there are many times where you just want something more than a single user boot to fix some breakage. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
On 06/01/2010 11:48 AM, Bill Nottingham wrote: > Elio Maldonado (emald...@redhat.com) said: > >> Not sure but I strongly suspect a change made to nss.spec to be the cause. >> See https://bugzilla.redhat.com/show_bug.cgi?id=596840#c7 >> > It's due to the fact that nss-softokn-freebl (actually, *all* the nss/nspr > libraires) do not fit the normal library naming, so it's not explicitly > pulled for > multilib. For any update or release set that's composed with a package that > explicitly > requires a compat arch of nss-softokn-freebl (such as glibc, libpurple, > pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13 > updates has none of these, so it doesn't. > > We could add some hacks to mash to get it pulled in, but I must ask... > why do all the NSS/NSPR libraries version their libraries in the library > name instead of the so version (i.e., libfreebl3.so instead of > libfreebl.so.3)? > Because upstream selected it's names before linux naming was anything like widespread. nss/nspr upstream was also unusual in considering binary compatibility breakage a sev 1 bug. It's expected that old apps run against new versions. One good side effect of this is there is no name colision in the libraries between Network Security Services and Name Switch Select, nor NSS's libssl3.so and openssl's libssl.so. bob smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, Jun 02, 2010 at 07:59:22PM +0200, Till Maas wrote: > On Wed, Jun 02, 2010 at 10:46:51AM -0700, Jesse Keating wrote: > > On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: > > > And I doubt that python scripts in below > > > /usr/lib/python2.6/site-packages usually need to be executable. Since > > > yum works without any problems, these tons of errors are useless, too. > > > And they make it only harder to find real errors. I did not think more > > > about the other quoted rpmlint messages. > > > > > > > > > > It's complaining because the files have #! in them, likely to assist in > > self tests, but the files aren't marked as executable. That could > > actually be fixed upstream, either mark them as executable or remove the > > #!s. > > I understand the rpmlint test, but I do not understand why this needs to > be handled upstream or why this is any problem at all. Are there > packages with executable files in the python-sitelib that need to be > executable or are used by users of the installed package as executables? > I think that was a list of three ways to fix the issue. As for not fixing the issue at all, that is probably a valid fourth option in most cases where python-sitelib is involved. What follows is just how I handle things, not how they must be handled: I like to get rid of the #! lines where the file in question is never going to be run as a script (It's just classes and functions, there's nothing in it to actually run and do anything). I submit these upstream and they are generally merged quickly. Marking as executable can be done when the module could be run as a script by a knowledgable user (one that knows that /usr/ib/python2.6/site-packages/foo/profiler.py can also be invoked from the command line) to do something they want. When the shebang is to allow running some sort of unittest I generally just leave it alone (the end user won't want to run it and upstream does want to run the code when they're testing). I generally try to remove as many rpmlint warnings as I can so that I can more plainly tell when something actually has regressed but in most cases involving python-sitelib, you don't gain anything from dealing with this warning. -Toshio pgp7ti7QFPiz6.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
Lennart Poettering wrote: > We wanted to make the transition from sysv to systemd very easy, and I > think this is the simplemost scheme we could come up with. During a > transition period packages should just ship both files and it'll work > with both init systems. s/systemd/upstart/ This is not the first time this has been said. Even though there may not be an initiative to switch from sysv to upstart, why do you feel so strongly that people will switch from sysv to systemd? Are you going to implement a Fedora policy that bans sysv, say, in Fedora 16? That's about the only way you could make it happen. If you can make everyone move away from sysv to something else, then by all means I'll do my best to aid in patches, but I don't have much confidence since everything that has been said about systemd has been said of upstart a few years ago. Instead of reinventing the wheel time and time again, there are other features that deserve attention. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 19:59 +0200, Till Maas wrote: > On Wed, Jun 02, 2010 at 10:46:51AM -0700, Jesse Keating wrote: > > On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: > > > And I doubt that python scripts in below > > > /usr/lib/python2.6/site-packages usually need to be executable. Since > > > yum works without any problems, these tons of errors are useless, too. > > > And they make it only harder to find real errors. I did not think more > > > about the other quoted rpmlint messages. > > > > > > > > > > It's complaining because the files have #! in them, likely to assist in > > self tests, but the files aren't marked as executable. That could > > actually be fixed upstream, either mark them as executable or remove the > > #!s. > > I understand the rpmlint test, but I do not understand why this needs to > be handled upstream or why this is any problem at all. Are there > packages with executable files in the python-sitelib that need to be > executable or are used by users of the installed package as executables? > *shrug* I suppose it's worth checking with upstream over it. And discussing whether that rpmlint rule should be removed in our build. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
2010/6/3 Matt McCutchen : > On Wed, 2010-06-02 at 20:00 +0200, Kevin Kofler wrote: >> Chen Lei wrote: >> > Is it right for the maintainer to provide two separate subpackages, >> > one with the tranditional rc.d contents and one with an upstart >> > scripts and make the -upstart subpackage have a higher priority over >> > sysinit subpackage? >> >> No. This is against our packaging guidelines. > > Where do you see that? > > -- > Matt > I'm not sure about whether ship upstart scripts violate our guidelines, but fedora package guideline has - "Currently, only SystemV-style initscripts are supported in Fedora". http://fedoraproject.org/wiki/PackagingGuidelines#Initscripts Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 13:25 -0400, Matt McCutchen wrote: > On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: > > Well, then lets begin: > > > > # rpmlint yum > > yum.noarch: W: self-obsoletion yum-allow-downgrade < 1.1.20-0 obsoletes > > yum-allow-downgrade [...] > Which of those messages do you consider noise and why? Most of them > look valid to me, though they are indeed nits. The self obsolete ones are wrong, being able to do: Name: foo Provide: bar = 2 Obsolete: bar <= 2 ...is completely legal and needed for rename/merging which is why yum has them. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 10:46 -0700, Jesse Keating wrote: > On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: > > And I doubt that python scripts in below > > /usr/lib/python2.6/site-packages usually need to be executable. Since > > yum works without any problems, these tons of errors are useless, too. > > And they make it only harder to find real errors. I did not think more > > about the other quoted rpmlint messages. > > > > > > It's complaining because the files have #! in them, likely to assist in > self tests, but the files aren't marked as executable. That could > actually be fixed upstream, either mark them as executable or remove the > #!s. > I've considered removing them in upstream just to shut rpmlint up. As irritating as that is. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, 2010-06-02 at 20:00 +0200, Kevin Kofler wrote: > Chen Lei wrote: > > Is it right for the maintainer to provide two separate subpackages, > > one with the tranditional rc.d contents and one with an upstart > > scripts and make the -upstart subpackage have a higher priority over > > sysinit subpackage? > > No. This is against our packaging guidelines. Where do you see that? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
2010/6/3 Kevin Kofler : > Chen Lei wrote: >> Is it right for the maintainer to provide two separate subpackages, >> one with the tranditional rc.d contents and one with an upstart >> scripts and make the -upstart subpackage have a higher priority over >> sysinit subpackage? > > No. This is against our packaging guidelines. You'll notice that all the > offending packages are by the same maintainer (you easily recognize them > from the ridiculous Release versions). > > All those -upstart and -lsb subpackages must go away and the -sysv > subpackages must be merged into the main package. > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > I found the maintainer violates fedora package/naming guideline many times, we need a people to persuade him to obey those guideline. A more ridiculous release number and a wrong version number: http://koji.fedoraproject.org/koji/buildinfo?buildID=176308 Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tor-lsb -- hey, look, package script, don't complain to _me_. I'm just installing you.
On Tue 1 June 2010 8:48:02 am Paul Wouters wrote: > I'm getting seriously tired of this tor package discussion every six > months. Seriously, just rip out the childish %post crap, and remove > all the non-fedora initscript sub package nonsense. This is not the > Enrico Project. Halfway there, if you're up for testing: https://bugzilla.redhat.com/show_bug.cgi?id=598213#c3 Ryan -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 597707] please update perl-Software-License to latest upstream release
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=597707 --- Comment #6 from Fedora Update System 2010-06-02 14:10:01 EDT --- perl-Software-License-0.101410-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Software-License'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-Software-License-0.101410-1.fc13 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 2, 2010 at 9:11 AM, Chris Adams wrote: > That would require systemd to be installed though, since otherwise > /etc/systemd doesn't exist (or every package that wants to drop a file > in there has to own it). > > I guess the directory could be added to chkconfig or even filesystem. That's an important note for the upcoming discussion over systemd integration. Having filesystem own the directory seems like the reasonable solution as part of systemd introduction...if it is decided that systemd is meant to be removable. That's an open question. Currently initscripts requires upstart explicitly for example. If the decision is made to use systemd instead...I fully expect that systemd will be a hard requirement for initscripts in a similar fashion to what we have right now as part of the systemd integration feature. And these upstart subpackages arent the only examples of upstart native scripts. vpnc seems to have grown a native upstart script already..with no sysinitv backup. We are already in the rabbithole. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: > On Wed, Jun 02, 2010 at 01:25:01PM -0400, Matt McCutchen wrote: > > On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: > > > > yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash > > > yum.noarch: E: non-executable-script > > > /usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python > > > Which of those messages do you consider noise and why? Most of them > > look valid to me, though they are indeed nits. > > Bash completion files are imho either always or never config files. So > it is either an error that needs to be fixed or not worth a warning. The right thing to do is to file a bug against bash-completion to get that decision made and then implement it, either by marking the file as config or moving /etc/bash_completion.d to /usr/share. The warning is not wrong. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
Jeff Spaleta wrote: > Even if systemd becomes the default, I doubt upstart is going to disappear > from the repository. Uh, IMHO it should get obsoleted by systemd and removed from the repository. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 597707] please update perl-Software-License to latest upstream release
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=597707 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System 2010-06-02 13:58:10 EDT --- perl-Software-License-0.101410-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Software-License'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-Software-License-0.101410-1.fc12 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: -upstart subpackage vs tranditional initscripts
Chen Lei wrote: > Is it right for the maintainer to provide two separate subpackages, > one with the tranditional rc.d contents and one with an upstart > scripts and make the -upstart subpackage have a higher priority over > sysinit subpackage? No. This is against our packaging guidelines. You'll notice that all the offending packages are by the same maintainer (you easily recognize them from the ridiculous Release versions). All those -upstart and -lsb subpackages must go away and the -sysv subpackages must be merged into the main package. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, Jun 02, 2010 at 10:46:51AM -0700, Jesse Keating wrote: > On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: > > And I doubt that python scripts in below > > /usr/lib/python2.6/site-packages usually need to be executable. Since > > yum works without any problems, these tons of errors are useless, too. > > And they make it only harder to find real errors. I did not think more > > about the other quoted rpmlint messages. > > > > > > It's complaining because the files have #! in them, likely to assist in > self tests, but the files aren't marked as executable. That could > actually be fixed upstream, either mark them as executable or remove the > #!s. I understand the rpmlint test, but I do not understand why this needs to be handled upstream or why this is any problem at all. Are there packages with executable files in the python-sitelib that need to be executable or are used by users of the installed package as executables? Regards Till pgp7eG5iYbcqM.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Curiosity, Are Cursor Themes that Critical?
On Wed, Jun 02, 2010 at 02:42:08AM +0530, Rahul Sundaram said > The former is the default theme and has been added as a dependency to a > core package. You are seeing a cascading set of dependencies as a result. Should that be done through comps? It's not a really required for functionality of those packages since there's always the possiblity to fall back to the old builtin bitmap cursors right? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote: > And I doubt that python scripts in below > /usr/lib/python2.6/site-packages usually need to be executable. Since > yum works without any problems, these tons of errors are useless, too. > And they make it only harder to find real errors. I did not think more > about the other quoted rpmlint messages. > > It's complaining because the files have #! in them, likely to assist in self tests, but the files aren't marked as executable. That could actually be fixed upstream, either mark them as executable or remove the #!s. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, Jun 02, 2010 at 01:25:01PM -0400, Matt McCutchen wrote: > On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: > > yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash > > yum.noarch: E: non-executable-script > > /usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python > Which of those messages do you consider noise and why? Most of them > look valid to me, though they are indeed nits. Bash completion files are imho either always or never config files. So it is either an error that needs to be fixed or not worth a warning. And I doubt that python scripts in below /usr/lib/python2.6/site-packages usually need to be executable. Since yum works without any problems, these tons of errors are useless, too. And they make it only harder to find real errors. I did not think more about the other quoted rpmlint messages. Regards Till pgpKWg40VPXot.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
about php-qa, phpUnderControl and meta packages
I am reposting this from fedora php-devel list to get a bigger audience. My questions are not that PHP specific: I got two questions regarding my effort to package more of the php-qa packages for fedora. I have made a package for phpUnderControl now, but to use it you still have to install CruiseControl by hand. phpUnderControl also patches the CruisceControl installation, so it isn't something that can easily packaged as an RPM. Does it still make sense to bring phpUnderControl into Fedora even though it requires an external software package? Second question: I would love to have a meta package which brings all of these packages ( phpunit, phpmd, phpcpd, phpdoc, phpcs, Mockery, ...) together and allows installation with one yum command. But as far as I could detect from the random posts it seems that meta packages are not really wanted on Fedora. An alternative is the comps list, but that doesn't allow for rapid changes and phpqa would be a bit specific. A third option would be to make something like phpUnderControl require all of these. The pear package already suggests some of them, but it isn't a hard require. My final goal is to make Fedora the best development environment for PHP, where you can get the full set-up of tools just with a few (or one) yum command. Ideally this would work on RHEL too, but I guess not before 6.0 and not for much after that because the shipped PHP release will too old again. With the Remi repository it would also work on older RHEL. Any suggestions are welcome :-) Cheers, Christof -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 14:48 +0200, Ralf Corsepius wrote: > Well, then lets begin: > > # rpmlint yum > yum.noarch: W: self-obsoletion yum-allow-downgrade < 1.1.20-0 obsoletes > yum-allow-downgrade [...] > yum.noarch: W: non-conffile-in-etc /etc/bash_completion.d/yum.bash > yum.noarch: E: non-executable-script > /usr/lib/python2.6/site-packages/yum/repos.py 0644L /usr/bin/python [...] > Or ... > # rpmlint binutils > binutils.x86_64: W: spelling-error %description -l en_US addr -> add, > adder, adds > binutils.x86_64: W: shared-lib-calls-exit > /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so e...@glibc_2.2.5 > binutils.x86_64: W: shared-lib-calls-exit > /usr/lib64/libbfd-2.20.51.0.2-20.fc13.so _e...@glibc_2.2.5 > binutils.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libopcodes-2.20.51.0.2-20.fc13.so /lib64/libz.so.1 > binutils.x86_64: W: no-manual-page-for-binary ld.bfd > binutils.x86_64: W: no-manual-page-for-binary ld.gold > binutils.x86_64: W: dangerous-command-in-%post rm > 1 packages and 0 specfiles checked; 0 errors, 7 warnings. Which of those messages do you consider noise and why? Most of them look valid to me, though they are indeed nits. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
Once upon a time, Jeff Spaleta said: > On Wed, Jun 2, 2010 at 8:37 AM, Lennart Poettering > wrote: > > Handling this with systemd is very easy: you can just drop in a file in > > /etc/init.d/foo *AND* /etc/systemd/system/foo.service from the same > > package. And then, if something that is not systemd is booted it will > > only see the init script. And if systemd is booted it will first look at > > the native service and ignore the init script if both exist. ALl that > > matters is that the "foo" part for both filenames is the same. > > Cool. When it comes time to put systemd in Fedora, please make sure > to note that in the Featuring documentation for packager guidance. That would require systemd to be installed though, since otherwise /etc/systemd doesn't exist (or every package that wants to drop a file in there has to own it). I guess the directory could be added to chkconfig or even filesystem. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 2, 2010 at 8:37 AM, Lennart Poettering wrote: > Handling this with systemd is very easy: you can just drop in a file in > /etc/init.d/foo *AND* /etc/systemd/system/foo.service from the same > package. And then, if something that is not systemd is booted it will > only see the init script. And if systemd is booted it will first look at > the native service and ignore the init script if both exist. ALl that > matters is that the "foo" part for both filenames is the same. Cool. When it comes time to put systemd in Fedora, please make sure to note that in the Featuring documentation for packager guidance. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 2, 2010 at 9:13 AM, Chen Lei wrote: > > Is it right for the maintainer to provide two separate subpackages, > one with the tranditional rc.d contents and one with an upstart > scripts and make the -upstart subpackage have a higher priority over > sysinit subpackage? No, that's crazy. The benefits of using the upstart syntax are small, and would be completely outweighed by the downsides of bloating the package set like this. It's also really undiscoverable; very few system administrators are going to be actively seeking out -upstart packages. Long term we need to pick one init system and change things to take advantage of it by default. Lennart's suggestion of shipping both in the main package seems quite sane. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: culmus-fonts packaging bug / Non-responsive maintainer
On Thu, 03 Jun 2010 00:07:24 +0900, Mamoru wrote: > Toshio Kuratomi wrote, at 06/02/2010 11:51 PM +9:00: > > On Wed, Jun 02, 2010 at 08:12:08PM +0900, Mamoru Tasaka wrote: > >> Michael Schwendt wrote, at 06/02/2010 06:49 PM +9:00: > >>> http://bugzilla.redhat.com/570819 > >>> > >>> A ticket opened on March 5th, but Pravin Satpute just doesn't > >>> respond. > >>> > >>> Does anyone know the languages involved here (lang=he, lang=yi) > >>> and can fix this fonts package, please? Thanks in advance. > >> > >> I will vote that this must be fixed in yum side (or fontconfig or rpm). > >> > > What's a commandline I can use to reproduce the warning? I can look at > > converting all of the data into bytes if I know how to test. > > Well, I just looked at the bug and I don't know how to reproduce this > bug exactly. Most simple test-case: 1) use Fedora 13 2) yum -y install yum-utils 3) repoclosure -n -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, 02.06.10 08:12, Jeff Spaleta (jspal...@gmail.com) wrote: > Assuming moving forward a maintainer has the option to support > sysinitv, upstart and systemd, what can be done to make sure the > correct init configuration is loaded on the system? Other than > including all the configs in the base package..I'm not sure I have a > useful suggestion for a solution to selection. And even then, if you > have the sysinitv installed side-by-side with the native upstart or > systemd config is that going to cause a conflict? Handling this with systemd is very easy: you can just drop in a file in /etc/init.d/foo *AND* /etc/systemd/system/foo.service from the same package. And then, if something that is not systemd is booted it will only see the init script. And if systemd is booted it will first look at the native service and ignore the init script if both exist. ALl that matters is that the "foo" part for both filenames is the same. We wanted to make the transition from sysv to systemd very easy, and I think this is the simplemost scheme we could come up with. During a transition period packages should just ship both files and it'll work with both init systems. I am not sure Upstart provides a similar scheme. I don't think so however. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rebuild of packages dependent on perl
On Wed, Jun 02, 2010 at 02:25:17PM +0200, Iain Arnell wrote: > On Tue, Jun 1, 2010 at 9:40 PM, Richard W.M. Jones wrote: > > > > If anyone fancies having a go at fixing perl4caml .. Debian reported > > a bug compiling this with Perl 5.12 already: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578800 > > > > It seems simplest to pretend that SVt_RV still exists on the caml > side; attached patch will do just that. Thanks Iain, I've pushed this upstream. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 19:07 +0300, Ville Skyttä wrote:
> On Wednesday 02 June 2010, Matthias Clasen wrote:
> > On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote:
> >
> > > Which packages do you maintain where the output has become unmanageable?
> >
> > For myself, I really only think that the spell checks are intolerable.
>
> There have been some complaints about them. I don't personally think that
> they're quite intolerable and the noise level should decrease over time as
> the
> spell checker dictionaries used by Enchant evolve, but if there's clear
> consensus that they cause more harm than good, they can be disabled in future
> default rpmlint package configs. Until then, you can do for example:
>
> # Disable Enchant spell check:
> echo 'setOption("UseEnchant", False)' >> ~/.config/rpmlint
>
> # ...and if you want the internal feeble spell checker msgs gone too:
> echo 'addFilter("spelling-error")' >> ~/.config/rpmlint
I can personally see the advantage to having warning possible to disable
per-pkg/release by the package owners. So that various other powers that
be can see what's being filtered out - but so the packager doesn't get
annoyed by things which are not useful.
heck - I could even see making it so the optin dir could have a 'filter'
file with the filters in it - but I think that's a bit much engineering
for a first run at things. Especially when the goal is to have a results
database with better accounting of this info.
-sv
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
a11y stack change
Just a heads-up: As part of the ongoing march towards GNOME3, I have switched the accessibility stack to default to the dbus stack (at-spi2-core/at-spi2-atk/pyatspi) instead of the Corba stack (at-spi). Some initial testing shows that orca and caribou seem to work ok. One issue that I've noticed so far is that firefox is unwilling to pop up menus when accessibility is turned on. I am working with the aeccessibility team upstream to resolve this and other issues that will no doubt pop up. If you notice problems that look like they might be related to this change, please let me know. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wed, 2010-06-02 at 08:54 -0400, Matthias Clasen wrote: > On Wed, 2010-06-02 at 08:36 -0400, seth vidal wrote: > > > > > I think the goal is, of course, to reduce the noise out and focus on > > making sure the packagers know about the truly broken. :) > > > > Another useful goal might be to only emit errors/warnings for which we > can accompany the message with a link to the section in the packaging > guidelines that explains how to avoid the problem. sure. I think there are a number of things which are "wrong" but not obviously a specific rule. For example: Your package seems to have grown by 1.5GB. or Hmm - you had 300 provides in the last package, this one has 25000. that seems _wrong_ but not clearly against any rule. :) -sv. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, Jun 02, 2010 at 12:11:26PM -0400, David Michael wrote:
> Hi,
>
> On Wed, Jun 2, 2010 at 11:42 AM, Richard W.M. Jones wrote:
> > I wonder what the performance impact is. NOPL appears to be a
> > variable length NOP (no-op). Obviously a very useful instruction for
> > things like alignment, and gcc seems to stuff lots of them into the
> > code:
> >
> > $ objdump -d /bin/ls | wc -l
> > 16867
> > $ objdump -d /bin/ls | grep nopl | wc -l
> > 369
> >
> > 369/16867 ~ 2%
> >
> > This is not a very fair comparison because we'd want to know how
> > frequently NOPL is executed, but I hope it shows that these
> > instructions are not infrequent.
>
> I recall checking this when F12 was declared to go i686 but retain
> support for Geode LX CPUs. NOPLs were common in x86_64, but seemed to
> be very infrequent in 32-bit land (which is what would run on a Geode
> anyway).
>
> To see if this is still the case, I downloaded and extracted F13's
> 32-bit coreutils, and no binary appears to contain a single NOPL.
> (Though I get a similar result as your test with x86_64.)
>
> objdump -d {,usr/}{,s}bin/* | grep -Fc nopl
> 0
Ah very true. I was forgetting that they were 32 bit.
(I even *have* one of them :-)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 2, 2010 at 5:21 AM, Patrice Dumas wrote: > That being said, it seems that the new init system, systemd is already in > the pipe. Doing a policy for an obsolete technology may be some time > lost. Maybe even better would be preparing a policy for systemd scripts > than doing a policy for upstart vs sysvinit. The only issue I really see is the high priority of the upstart config. Is that deliberately or is that just how it works out because of the package naming which influences the yum depresolution scoring. Whatever the reason I'm The existence of the subpackages aren't strictly a problem necessarily. But they definitely complicate thingsif we want to do more than just ensure the default init system config is installed on the system. Even if systemd becomes the default, I doubt upstart is going to disappear from the repository. Some people are going to want to use it and some maintainers will support it with native configs. The question is how do we make sure the correct init file that is compatible with the init system in use on the system is installed. Assuming moving forward a maintainer has the option to support sysinitv, upstart and systemd, what can be done to make sure the correct init configuration is loaded on the system? Other than including all the configs in the base package..I'm not sure I have a useful suggestion for a solution to selection. And even then, if you have the sysinitv installed side-by-side with the native upstart or systemd config is that going to cause a conflict? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
Hi,
On Wed, Jun 2, 2010 at 11:42 AM, Richard W.M. Jones wrote:
> I wonder what the performance impact is. NOPL appears to be a
> variable length NOP (no-op). Obviously a very useful instruction for
> things like alignment, and gcc seems to stuff lots of them into the
> code:
>
> $ objdump -d /bin/ls | wc -l
> 16867
> $ objdump -d /bin/ls | grep nopl | wc -l
> 369
>
> 369/16867 ~ 2%
>
> This is not a very fair comparison because we'd want to know how
> frequently NOPL is executed, but I hope it shows that these
> instructions are not infrequent.
I recall checking this when F12 was declared to go i686 but retain
support for Geode LX CPUs. NOPLs were common in x86_64, but seemed to
be very infrequent in 32-bit land (which is what would run on a Geode
anyway).
To see if this is still the case, I downloaded and extracted F13's
32-bit coreutils, and no binary appears to contain a single NOPL.
(Though I get a similar result as your test with x86_64.)
objdump -d {,usr/}{,s}bin/* | grep -Fc nopl
0
> Having said that, AMD Geodes are sloww anyway ...
I wouldn't exactly use it as a gaming rig, but a silent wireless
computer on <5W power can always be used for something.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-05-27 i386
On Tue, Jun 01, 2010 at 04:52:42AM +0200, Ralf Corsepius wrote: > On 05/31/2010 07:44 PM, Matt Domsch wrote: > > Fedora Fails To Build From Source Results for i386 > > using rawhide from 2010-05-27 > > > > This is a full rebuild, the first for Fedora 14's rawhide. The > > builders all have Fedora 13 installed. > > > OpenSceneGraph-2.8.2-3.fc12 (build/make) corsepiu > > From > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/OpenSceneGraph-2.8.2-3.fc12.src.rpm/result/build.log: > > extracting debug info from > /builddir/build/BUILDROOT/OpenSceneGraph-2.8.2-3.fc14.i386/usr/lib/osgPlugins-2.8.2/osgwrapper_osgVolume.so > extracting debug info from > /builddir/build/BUILDROOT/OpenSceneGraph-2.8.2-3.fc14.i386/usr/lib/osgPlugins-2.8.2/osgwrapper_osgViewer.so > extracting debug info from > /builddir/build/BUILDROOT/OpenSceneGraph-2.8.2-3.fc14.i386/usr/lib/osgPlugins-2.8.2/osgwrapper_osgUtil.so > /usr/lib/rpm/find-debuginfo.sh: line 90: 3300 Bus error > (core dumped) eu-strip --remove-comment $g -f "$1" "$2" > error: Bad exit status from /var/tmp/rpm-tmp.1Jia6Z (%install) > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.1Jia6Z (%install) > Child returncode was: 1 > EXCEPTION: Command failed. See logs for output. > > ?!? It succeeded when not using tmpfs, so nothing to look at here. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package maintainers -- want test results by mail?
On Wednesday 02 June 2010, Matthias Clasen wrote:
> On Wed, 2010-06-02 at 07:49 -0400, James Laska wrote:
>
> > Which packages do you maintain where the output has become unmanageable?
>
> For myself, I really only think that the spell checks are intolerable.
There have been some complaints about them. I don't personally think that
they're quite intolerable and the noise level should decrease over time as the
spell checker dictionaries used by Enchant evolve, but if there's clear
consensus that they cause more harm than good, they can be disabled in future
default rpmlint package configs. Until then, you can do for example:
# Disable Enchant spell check:
echo 'setOption("UseEnchant", False)' >> ~/.config/rpmlint
# ...and if you want the internal feeble spell checker msgs gone too:
echo 'addFilter("spelling-error")' >> ~/.config/rpmlint
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Tue, 2010-06-01 at 22:43 +0200, Gland Vador wrote: > Sorry to reopen this old topic, but the conclusion is not obvious. The > F13 is out and it seems to have lost support for the Geode LX CPU > (cf.http://sharkcz.livejournal.com/5708.html), due to the use of the > NOPL instruction by GCC. > > Will this CPU be supported during F13 and above or should I search for a > new distribution ? I really, really think primitive x86 support should be done as a secondary arch. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-05-27 x86_64
On Mon, 2010-05-31 at 12:43 -0500, Matt Domsch wrote: > nphilipp: gegl,gtkimageview,ufraw these all built fine as scratch, probably affected by the segfaulting pkgconfig -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i386-class support changed in F-13?
On Wed, Jun 02, 2010 at 11:23:37AM -0400, David Michael wrote: > On Wed, Jun 2, 2010 at 2:39 AM, Peter Robinson wrote: > > It does work in F-12, the response for the lack of support in F-13 was > > 'deal with it'. There is suppose to be a patch to emulate it in the > > kernel but apparently it won't go upstream until its a generic infra > > patch that can allow support of other emulated bits in other cpus in a > > generic way. So its possible it will come back, but I don't hold up > > hope of a quick resolution. Which leaves us in a big predicament as to > > how we're going to support the 1.5 million odd XO-1s out there moving > > forward. > > I believe this was the latest post of the NOPL emulation patch: > http://lkml.org/lkml/2010/3/1/430 This is not the general instruction > emulator mentioned, but a fix intended just for getting the Geode LX > classed as i686. > > I haven't used this patch myself yet; my Geode LX machine runs an > older Fedora, so it still works. I suppose I'll need to try the patch > during the next upgrade until things are settled. I wonder what the performance impact is. NOPL appears to be a variable length NOP (no-op). Obviously a very useful instruction for things like alignment, and gcc seems to stuff lots of them into the code: $ objdump -d /bin/ls | wc -l 16867 $ objdump -d /bin/ls | grep nopl | wc -l 369 369/16867 ~ 2% This is not a very fair comparison because we'd want to know how frequently NOPL is executed, but I hope it shows that these instructions are not infrequent. Having said that, AMD Geodes are sloww anyway ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
