Why do gating tests start out 'failed'?
Hi, I've just enabled gating tests for gfs2-utils and after the new build finished I got a notification email from bodhi that said: "This update's test gating status has been changed to 'failed'." On the bodhi update page[0] the "fedora-ci.koji-build.tier0.functional" test was highlighted red and marked as failed, with no extra information available. After a while, the original 'failed' test turned green and showed successful, which was puzzling. Why was it marked failed in the first place? All's well that ends well, but I wasted a bit of time trying to work out why it had failed when it really hadn't... [0] https://bodhi.fedoraproject.org/updates/FEDORA-2020-6f310e98bb By the way, do gating tests have permission to mount filesystems in the test environment? It would be really useful for testing the gfs2 utils that require a mounted fs. Cheers, Andy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: delta rpms - can we turn them off
Hi Troy, On 27/06/14 16:26, Troy Dawson wrote: It is a hidden default that is not in any man page or documentation. Did you look for deltarpm in the yum.conf man page? If it's missing then that might be the problem (it's there on my x86_64 F20 machines at least). Cheers, Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Very slow trackpad after install latest F20 updates
On 27/06/14 23:58, Sergio Pascual wrote: Hello, I have updated two laptops runing F20 today. After the update, on both of them (Asus and Dell) the trackpad has turned very slow, and unaffected of any change in the gnome control panel. Try this update: https://admin.fedoraproject.org/updates/FEDORA-2014-7810/xorg-x11-server-1.14.4-11.fc20 Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Are wildcards permitted in Requires: lines in spec files?
On 16/05/14 11:28, Richard W.M. Jones wrote: Are they permitted, and do they work? Specifically I need to install all the Xorg drivers (since I don't know what hardware will be installed on the target machine), thus: Requires: xorg-x11-drv-* I'm not sure if they work but I think a wildcard would be too broad in most cases anyway (could pull in -debuginfo packages, etc. too) but this should help in your case: https://admin.fedoraproject.org/pkgdb/package/xorg-x11-drivers/ The purpose of this package is to require all of the individual X.Org driver rpms, to allow the OS installation software to install all drivers all at once, without having to track which individual drivers are present on each architecture. By installing this package, it forces all of the individual driver packages to be installed. Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
On 24/04/14 15:13, Lennart Poettering wrote: We probably should make setjmp()-freeness a requirement for all code included in Fedora. Would it be worth the effort, and how feasible is it anyway? - Do we have any usage statistics? - How often do we see bugs caused by bad uses of setjmp/longjmp? - Is mitigation instead of blanket removal possible? - How likely is it that /all/ setjmp/longjmp uses can be reasonably replaced? - Is there existing upstream momentum to move away from setjmp/longjmp? (I'm not against the idea but I think it deserves further discussion.) Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gcc build with -O0 results in corrupted -debuginfo package
On 25/04/14 20:10, Simo Sorce wrote: On Fri, 2014-04-25 at 14:03 -0400, Adam Jackson wrote: On Fri, 2014-04-25 at 18:10 +0200, Kevin Kofler wrote: Petr Spacek wrote: I'm going to reproduce and debug issue in named. Do you see any specific reason why I should use -O2 for serious debugging/development sessions? IMHO, you should always debug with optimization enabled. s/debug/test/ IMHO. Kevin, have you ever debugged with -O2 ? It's more than reasonable to want -O0. At -O2 some code becomes really annoying to follow because gcc will optimize away way too much of it into registers (and gdb will not print you the values you need to see) or will make stepping a nightmare with gdb jumping in an out of the function as it gets inlined and then some stuff moved out of the original function and things like that. I've been more than once in gdb with -O2, it is *not* pretty, nor useful. +1 debug symbols at -O2 are mostly useful to get backtraces, but if you need to really step through with gdb in some complicated, highly optimizable code, often it does not cut it, you have to rebuild with -O0 to regain debuggability and sanity. -Og (new in gcc 4.8) is meant to enable only optimizations which won't confuse gdb but I've not found a need to optimize my code just a little bit while debugging yet, so -O0 is still my --enable-debug flag. Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: trimming down Fedora installed size
On 11/04/14 21:54, Richard W.M. Jones wrote: On Thu, Apr 10, 2014 at 06:13:42PM +0100, Andrew Price wrote: On 10/04/14 17:05, Bill Nottingham wrote: James Antill (ja...@fedoraproject.org) said: Not that I assume splitting lanauges and docs. into sub packages would triple primary numbers, but if it did ... that would be bad. To put it in perspective, if we split out 'langpacks' for apps per language, something like gedit then grows *100* new subpackages. Bill It's a shame we can't store .mo files compressed. Unfortunately .mo files are mmapped and shared between processes, so compressing them wouldn't work :-( That's what I thought :/ Just thinking out loud, but maybe with an updated gettext(3) it could work, but I guess it would require some hefty changes in libc, right? Unless programs could be linked against a zintl lib to provide an alternative gettext(3) perhaps. Either way it would need to be transparently backward compatible with the current .mo format and obviously there'd be performance concerns for some programs so they'd need to stick with the current implementation. Portability shouldn't be an issue though as .po files can be compiled to whatever .mo format the distro/package uses. I think there's potential for innovation in that area anyway, but it would need some momentum behind it. Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: trimming down Fedora installed size
On 10/04/14 17:05, Bill Nottingham wrote:
James Antill (ja...@fedoraproject.org) said:
Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but if it did ... that would be bad.
To put it in perspective, if we split out 'langpacks' for apps per language,
something like gedit then grows *100* new subpackages.
Bill
It's a shame we can't store .mo files compressed. The ratio seems quite
good:
[root@phanto ~]# cd /usr/share
[root@phanto share]# cp -r locale locale-compressed
[root@phanto share]# find locale-compressed -type f -name '*.mo' -exec
bzip2 --best {} \;
[root@phanto share]# du -sh locale locale-compressed
657Mlocale
245Mlocale-compressed
(NB this isn't a newly installed system.)
Andy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What is support status of PowerVR GPUs in Fedora? (Intel D2500 and gma500_gfx)
On 14/11/13 15:59, Adam Jackson wrote: On Thu, 2013-11-14 at 13:05 +0100, valent.turko...@gmail.com wrote: I'm really interested what is the state of gma500_gfx driver in latest kernel, is it reasonable to expect that this driver will get updated and have better support or should I just say to my friend to grab version of Windows 7 and to run with it... any suggestions? Intel's PowerVR-based graphics have _terrible_ support in Linux. They've been promising for years to either a) provide a competent free driver and/or b) stop producing pvr-based chipsets, and they have repeatedly failed at both. There is no OSS 3D driver for these chips, which is unfortunate, since 3D is the only thing these chips do even remotely well, and they're inevitably attached to underpowered CPUs where llvmpipe isn't going to help much. There's a KMS driver that vaguely works kinda sometimes, as you've found, but that just lights up the display, it doesn't provide any acceleration. I do not expect support for these chips to get materially better any time soon. Honestly at this point I don't even want to reverse engineer the things, it would essentially be rewarding Intel for bad behaviour. On the one hand, you're absolutely right. On the other hand, I own a Samsung NC110 netbook which has one of these PowerVR suckers in it so I deeply appreciate the excruciatingly laborious work that these folks are doing: http://powervr.gnu.org.ve/doku.php (site seems broken at the moment :( ) http://libreplanet.org/wiki/Group:PowerVR_drivers (decent summary) Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Where are we going? (Not a rant)
Ah the ol' Fedora stability improvement thread. It must be Friday. Ok, I'll bite. This sort of conversation often comes and goes without much being done. Usually it consists of debates between three camps: 1. Those who see Fedora as an intrinsically unstable distro which showcases and attracts testing for the latest upstream work 2. Those who want Fedora to be stable enough to become a realistic alternative to Windows and Ubuntu for the general masses 3. Those who want Fedora to be stable enough and supported for long enough to be used as a server OS I think the reason nothing happens is due to the core issue not being agreed upon by all camps. It's very difficult to make progress on a solution unless you first understand and agree on the problem. However, if you're still interested I've laid out some ideas, based on my belief that instability is a significant problem, below. On 07/12/12 12:53, Tomas Radej wrote: One of the results was a conversation I had with a few guys to whom I recommended Fedora as a development environment. It showed me that there's indeed something wrong. While they all said that Fedora's features were brilliant, they unanimously rejected Fedora as a primary system. The reason they gave me was, now quoting: It doesn't really work. One hypothesis is that too few people use Rawhide to a point where enough testing gets done before final releases. I think making some basic guarantees about Rawhide's stability (it boots, package management works, etc.) would go some way to increase early adoption and ensure bugs are reported and fixed before final releases, thus avoiding many unnecessary updates. I would certainly consider running Rawhide with such guarantees. Once most of us are dog-fooding Rawhide the temptation to release the latest unstable upstream code in stable release updates would be significantly reduced and our update policy could be tightened to disallow version bumps, etc. in stable release updates similar to other, more popular distros' update policies. I think this is a better first step forward than LTS releases because it focuses on users' first impressions of Fedora by increasing the stability level on the day of release. Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where are we going? (Not a rant)
On 07/12/12 17:48, Matthew Miller wrote: On Fri, Dec 07, 2012 at 03:11:31PM +, Andrew Price wrote: Ah the ol' Fedora stability improvement thread. It must be Friday. Ok, I'll bite. This sort of conversation often comes and goes without much being done. Usually it consists of debates between three camps: 1. Those who see Fedora as an intrinsically unstable distro which showcases and attracts testing for the latest upstream work 2. Those who want Fedora to be stable enough to become a realistic alternative to Windows and Ubuntu for the general masses 3. Those who want Fedora to be stable enough and supported for long enough to be used as a server OS Hmmm. I don't think I'm in any of those camps. I want Fedora to thrive and be used, not as an alternative but on its own merits. Each OS is an alternative to the others. Alternative here shouldn't imply anything negative, simply that users could happily switch from one to the other. That includes being a general-purpose OS, both on desktops, on traditional servers, and in the cloud. Well that's my hope, too. The items on your list are compatible with each other but the problem arises when you add the requirement for Fedora to additionally be an unstable mixing pot of the latest upstream packages. And that's really what rawhide should be, but since rawhide requires so much effort to install and keep running, that's what Fedora proper has become. While I *do* think we would benefit from a slightly longer cycle (with an security updates only phase), I don't think that's the only way to tackle the problem. I'm not against extending the cycle in essence. I just don't think the *first* step should be to extend cycles and/or support. I think we need the ability to tackle as many stability problems as we can, pre-release, before we can start thinking about extending life cycles, and that means getting people using rawhide day-to-day again. The more bugs we allow into our releases by neglecting to test rawhide, the more development time we have to spend/waste on fixing packages in the three supported releases. I would link to http://lwn.net/Articles/506831/ but you were quoted in that article so I'm guessing you've already seen it :) For example, making it so key applications and development stacks could easily float from one base OS to the next would make it less of an issue when the base OS needs to be upgraded. Not sure I catch your drift here, but it sounds like it could cause API mismatch headaches. Making upgrades incredibly painless is another good but different approach, making us closer to a rolling release. (I think we're headed that way with 'fedup', but it's going to be a little longer for that to shake out.) Yep, I upgraded my netbook to f18 beta with fedup yesterday without too much hassle. Looks promising. Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: should I see a F18 branch?
On 03/09/12 23:31, Neal Becker wrote: Ken Dreyer wrote: On Mon, Sep 3, 2012 at 4:01 PM, Neal Becker ndbeck...@gmail.com wrote: fedpkg pull Already up-to-date. git branch f12 f13 f14 f15 f16 * f17 master git pull -a will grab the f18 branch. Not sure why fedpkg doesn't do it. - Ken $ git pull -a Already up-to-date. $ git branch f12 f13 f14 f15 * f16 f17 master Try 'git branch -a' or 'fedpkg switch-branch': $ git branch -a f15 f16 f17 * f18 master remotes/origin/HEAD - origin/master remotes/origin/f13 remotes/origin/f14 remotes/origin/f15 remotes/origin/f16 remotes/origin/f17 remotes/origin/f18 remotes/origin/f7 remotes/origin/f8 remotes/origin/f9 remotes/origin/master $ fedpkg switch-branch Locals: f15 f16 f17 * f18 master Remotes: origin/f13 origin/f14 origin/f15 origin/f16 origin/f17 origin/f18 origin/f7 origin/f8 origin/f9 origin/master Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving pid files from /var/run/$name.pid to /var/run/$name/$name.pid
On 24/08/12 13:41, Colin Walters wrote: On Fri, 2012-08-24 at 10:08 +0200, Hans de Goede wrote: /var/run/$name.pid is the standard pid file location for daemons and has been so for ages. A lot of distros depend on this, and we used to depend on it until we moved to systemd which no longer cares about pid files. Right, so why not just configure the daemon to stop writing the pid file at all? From systemd.service(5): PIDFile= Takes an absolute file name pointing to the PID file of this daemon. Use of this option is recommended for services where Type= is set to forking. systemd will read the PID of the main process of the daemon after start-up of the service. If Type=forking is set and PIDFile is unset, systemd will try to guess the PID of the main daemon process. I'm not sure what the guessing strategy is but specifying the PIDFile explicitly is probably safer, particularly for daemons which spawn 1 processes. Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 24/01/12 12:24, Richard W.M. Jones wrote: On Tue, Jan 24, 2012 at 11:23:14AM +, mike cloaked wrote: Fedora would appear to be out of line in not taking on board the potential user base for a rolling release version. For servers there would be huge advantages in management of systems. I doubt your claims here. Fedora already has a perfectly good rolling release. It's called Rawhide, and I run it on my laptop. I'd be nuts to run it on a server. I run Debian Testing (a rolling release) on my desktop machine. I wouldn't recommend it for servers either, but I find it roughly as stable as Fedora releases. Why? Because the equivalent of Rawhide in Debian is Debian Unstable and packages have to be critical-bug-free in Unstable for a time before they graduate to Testing. If there was a rolling repository like this sitting between Rawhide and Fedora N+1 then I'd most certainly use it. As it is, I'm quite happy using Fedora 16 on my laptop until 17 is released. Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Removing SysV Init Scripts
Hi, On 18/01/12 22:42, BJ Dierkes wrote: Sorry, I didn't mean to start a heated thread on SysV vs. Systemd or anything. Unfortunately my question wasn't really answered. I *am* removing SysV support from gearmand … and have already implemented Systemd scripts. My question is… for existing users still on SysV in Fedora 17 …. are there any safeguards I need to put in place as to not break them… or should I just rip out all the SysV stuff and hope for the best? I'm not sure if this is what you're looking for but when I migrated a package to systemd I used the spec file tips from this page: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd (Specifically the section entitled Packages migrating to a systemd unit file from a SysV initscript) Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Systemd and fstab
Hi, From the systemd.mount(5) man page: Mount units may either be configured via unit files, or via /etc/fstab This makes me wonder - to what extent will systemd replace fstab in future Fedoras? Will fstab disappear in favour of systemd mount units? Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
