Re: [fedora-arm] Fedora 17 ARM Beta Release
On 05/23/2012 10:53 PM, rihowa...@gmail.com wrote: http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_Beta I do not see any files listed with kirkwood kernels. What happened to the files that came with kirkwood kernels? We didn't do image testing on kirkwood devices (dreamplug, guruplug) for the final beta spin, so it was not included. We are generating them every night though, so if you'd like to try a *completely untested* Kirkwood image, you'll find one at the following location: http://scotland.proximity.on.ca/arm-nightlies/ -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need some packages to be reviewed.
Hey Volker, I'll go through your package over the weekend and review it. I hope that would be fine. -- Aditya Patawari http://blog.adityapatawari.com/ https://fedoraproject.org/wiki/User:Adimania India On Wed, May 23, 2012 at 5:58 PM, Volker Fröhlich volke...@gmx.at wrote: Am Mittwoch, 23. Mai 2012, 16:19:22 schrieb Aditya Patawari: Hey, I am looking for some kind people to review the following packages: Carbon: https://bugzilla.redhat.com/show_bug.cgi?id=824348 graphite-web: https://bugzilla.redhat.com/show_bug.cgi?id=824357 whisper: https://bugzilla.redhat.com/show_bug.cgi?id=824361 I'd trade whisper for: https://bugzilla.redhat.com/show_bug.cgi?id=812559 Volker Fröhlich -- Aditya Patawari http://blog.adityapatawari.com/ https://fedoraproject.org/wiki/User:Adimania India -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How to proceed with MiniDebugInfo
I'm at a loss to how to proceed with the MiniDebugInfo work. I have patches to rpmbuild that creates the compressed minidebuginfo putting them in the main binaries, and I have patches to gdb that reads the compressed debuginfo on demand. However, the whole thing is useless unless we agree that we want to enable this by default. It seems some people like the idea, whereas others disagree that its worth the increased binary size. It doesn't look like either side is gonna be able to convince the other side, so how do we get to a decision here? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, 24 May 2012 09:28:16 +0200, Alexander Larsson wrote: However, the whole thing is useless unless we agree that we want to enable this by default. It seems some people like the idea, whereas others disagree that its worth the increased binary size. It doesn't look like either side is gonna be able to convince the other side, so how do we get to a decision here? It is difficult to agree on something when you still have not accepted why some people disagree with it. I do not mind the size, as for example we lose already 5-10% by not using gold (unused + duplicate template methods). I mind that in all aspects better solution is ABRT and we should put more effort to it and not to some temporary poor solutions. (This is very generalized to avoid the discussion again.) Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/24/2012 02:38 AM, Gerry Reno wrote: What does Fedora do currently, if anything, to optimize for solid-state drives (SSD). Things like swap and logging can generate a huge number of writes. So I suppose those should maybe be placed on a rotating drive if one is available but if not does Fedora do anything to reduce the amount of writes? Or is everything related to SSD the responsibility of the user? I think Fedora aligns partitions to 1MiB boundaries and disables atime (with relatime), both things are good for SSD drives. Using tmpfs for /tmp is also ok. I've been using SSD drives for a couple of years, and in my opinion concerns about logs and swap are exaggerated. And having swap on SSD is a GREAT thing if you use hibernation. :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, 2012-05-24 at 09:35 +0200, Jan Kratochvil wrote: On Thu, 24 May 2012 09:28:16 +0200, Alexander Larsson wrote: However, the whole thing is useless unless we agree that we want to enable this by default. It seems some people like the idea, whereas others disagree that its worth the increased binary size. It doesn't look like either side is gonna be able to convince the other side, so how do we get to a decision here? It is difficult to agree on something when you still have not accepted why some people disagree with it. I do not mind the size, as for example we lose already 5-10% by not using gold (unused + duplicate template methods). I mind that in all aspects better solution is ABRT and we should put more effort to it and not to some temporary poor solutions. (This is very generalized to avoid the discussion again.) And its difficult for me to understand how do you continue to claim in all aspects better when comparing the two, An offline solution that always produces at least something usable to a online one that requires all-star alignment of circumstances to produce the perfect backtrace result. There is no basis for one-or-the-other comparison. IMHO its is a good thing for lightweight, kernel-like userspace backtraces to become widely desseminated across the webs. Regards Yanko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On 05/24/2012 10:28 AM, Alexander Larsson wrote: I'm at a loss to how to proceed with the MiniDebugInfo work. I have patches to rpmbuild that creates the compressed minidebuginfo putting them in the main binaries, and I have patches to gdb that reads the compressed debuginfo on demand. However, the whole thing is useless unless we agree that we want to enable this by default. It seems some people like the idea, whereas others disagree that its worth the increased binary size. It doesn't look like either side is gonna be able to convince the other side, so how do we get to a decision here? Pass the feature to FESCo? For anything remotely controversial (and judging by past discussion on the subject, this counts as one), you're unlikely to get what amounts to an actual decision on fedora-devel... - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
2012/5/24 Gerry Reno gr...@verizon.net What does Fedora do currently, if anything, to optimize for solid-state drives (SSD). Things like swap and logging can generate a huge number of writes. So I suppose those should maybe be placed on a rotating drive if one is available but if not does Fedora do anything to reduce the amount of writes? Or is everything related to SSD the responsibility of the user? Apart from correctly aligning the partitions, I think there are no more optimizations done by Fedora. I use a SSD and to get the best performance I use ext4 directly on the partitions, without LVM, Luks, RAID, etc. Also, here are a few tips: - Mount options: noatime to reduce writes. discard if your unit supports TRIM - Change the default scheduler: I created /etc/rc.d/rc.local with: #!/bin/bash /bin/echo noop /sys/block/sda/queue/scheduler - Disable the readahead service: systemctl disable systemd-readahead-collect.service systemctl disable systemd-readahead-replay.service -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On Thu, May 24, 2012 at 10:30 AM, Juan Orti Alcaine j.orti.alca...@gmail.com wrote: 2012/5/24 Gerry Reno gr...@verizon.net What does Fedora do currently, if anything, to optimize for solid-state drives (SSD). Things like swap and logging can generate a huge number of writes. So I suppose those should maybe be placed on a rotating drive if one is available but if not does Fedora do anything to reduce the amount of writes? Or is everything related to SSD the responsibility of the user? Apart from correctly aligning the partitions, I think there are no more optimizations done by Fedora. I use a SSD and to get the best performance I use ext4 directly on the partitions, without LVM, Luks, RAID, etc. Also, here are a few tips: - Mount options: noatime to reduce writes. discard if your unit supports TRIM Yeah those too make sense (even though realatime should be enough). - Change the default scheduler: I created /etc/rc.d/rc.local with: #!/bin/bash /bin/echo noop /sys/block/sda/queue/scheduler This does not gain you much and hurts in some workloads. - Disable the readahead service: systemctl disable systemd-readahead-collect.service systemctl disable systemd-readahead-replay.service systemd should just do that by default (it disables it already when running on a VM). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: changelog in spec file, was Re: Stop the git abuse
Quoting Paul Wouters (2012-05-21 02:02:23) On Fri, 18 May 2012, Richard W.M. Jones wrote: On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote: And definitvely, for me, (and probably only for me), git is really not a good tool for spec maintenance. Not duplicating the changelog would help. There's little reason to have a changelog in git which is then manually copied into %changelog. Agreed. changelog and version field conflicts are 90% of my cherry-pick conflicts. I would be in favour of no longer maintaining a changelog in the spec file OK. Many of us agree that rpm changelogs could be generated from git. Now there are multiple approaches. As was said before Mageia/Mandriva have been doing it for a while. However I dislike approach of specific commit messages that will remove commit from changelog. Instead my proposal (that I am willing to work on with relengs/infra): * If there is a changelog in spec we assume packager keeps its changelog manually so we leave it be. This gives everyone time to adjust as they see fit. * By default add every git commit message except merges to rpm changelog on koji. I.e. no action from packager necessary * If a git commit is tagged in a specific way, omit from rpm changelog. What I mean by tagged is a git tag, in form of let's say silentXXX. Where XXX has to be unique, but that can be figured out by fedpkg easily. The way I see it, this could be relatively painless migration where packagers would not have to change their workflows immediately. Does anyone have any strong opinions against this approach? Note that I am not asking you to express your dislike for git changelog generation. You will have time for that later for sure -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, 2012-05-24 at 11:22 +0300, Yanko Kaneti wrote: On Thu, 2012-05-24 at 09:35 +0200, Jan Kratochvil wrote: On Thu, 24 May 2012 09:28:16 +0200, Alexander Larsson wrote: However, the whole thing is useless unless we agree that we want to enable this by default. It seems some people like the idea, whereas others disagree that its worth the increased binary size. It doesn't look like either side is gonna be able to convince the other side, so how do we get to a decision here? It is difficult to agree on something when you still have not accepted why some people disagree with it. I do not mind the size, as for example we lose already 5-10% by not using gold (unused + duplicate template methods). I mind that in all aspects better solution is ABRT and we should put more effort to it and not to some temporary poor solutions. (This is very generalized to avoid the discussion again.) And its difficult for me to understand how do you continue to claim in all aspects better when comparing the two, An offline solution that always produces at least something usable to a online one that requires all-star alignment of circumstances to produce the perfect backtrace result. There is no basis for one-or-the-other comparison. IMHO its is a good thing for lightweight, kernel-like userspace backtraces to become widely desseminated across the webs. I obviously agree with this, and disagree with Jan, but I'd like to avoid just repeating the previous discussion. The disagreement seems to be about two things: 1) Any binary size increase is bad (as it affects cd sizes, etc) 2) The results of the MiniDebugInfo is not perfect, and there is a theoretically perfect approach. So we should not spend time/energy/space/bits/whatever on the non-perfect appraoch. However, the perfect approach has other disadvantages due to being online/centralized, so I and others think its worth having both. The increased space is clearly a project global wide question that probably has to be decided by Fesco. The duplication of effort less so IMHO, as different people are doing the work. If we don't do minidebug I will not be spending any resources on the ABRT server anyway. So, not doing minidebug will not affect ABRT positively, and doing it will not affect it negatively (in fact, it might have a slight positive effect as it can use the low quality info when offline). But still, as this is mainly a resource/project management disagreement it might make sense to have Fesco look at it too. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On 05/23/2012 06:30 PM, Jesse Keating wrote:
On 05/22/2012 11:53 PM, Panu Matilainen wrote:
Well, here's what I see after drop_caches=3 from 'strace -tt fedpkg
verrel' on kernel.spec which is one of the most complicated specs in
Fedora land:
09:09:06.928011 fedpkg exec
09:09:12.699345 python imports done
09:09:13.510192 rpm exec
09:09:15.345425 rpm exit
09:09:15.385441 fedpkg exit
So by the look of things, 2/3 of the execution time is spent importing
python modules. The rpm execution time is heavily dependent on what the
spec actually does, eg in case of kernel.spec this includes ~50
fork+execs of shell, getconf and two python invocations from executing
shell macros.
From plain rpmspec parsing POV (shell macros aside), at top of
callgrind charts sits the rpm bad performance hallmark pattern of
repeated insert/delete, qsort and bsearch cycles (on macros). Changing
the macros engine to use a hash table instead has been on my todo list
for some time now, just not very high in the priorities as spec parse
isn't exactly the most time-critical thing rpm does.
OOps, I hope my message didn't come across as placing blame or throwing
rpm under the bus.
Oh, when rpm does something stupid it deserves the blame as much as the
next guy :) I *know* there are ugly scalability issues in rpmbuild
elsewhere, it wouldn't exactly shock me to find them in spec parsing as
well.
This was the first time ever I saw spec parsing being mentioned as a
bottleneck so I thought I'd had a look: while spec parse has
traditionally been but a drop in the ocean of package build time, times
do change and so do usage patterns. For one, the change from cvs to git
has changed the speed expectations quite dramatically.
I suspected it was a spec much like the kernel that
does a lot of complicated macro work to figure out things like name,
version, release. Also, I meant it as something I can't do much about in
fedpkg land.
Yup. And obviously rpm can't make eg the shell run any faster, but there
should be plenty of opportunities for eliminating some of the more
expensive invocations.
Take for example the ubiquitous python_sitelib/python_sitearch macros:
these invoke shell which invokes the python interpreter which imports
piles of stuff in order to get a couple of paths that are for all
practical purposes static within a Fedora release, and could be
statically defined from macro files generated at the main python
package(s) build-time.
Another, probably less expensive but even more ubiquitous that could be
fixed centrally is invoking shell + getconf through %{_smp_mflags} to
get the number of cpus, another pretty static piece of information.
A different kind of case of unnecessary shell invocations slowing things
down is doing simple arithmetics and such, when %{lua: ...} could be
used, but that's obviously something that individual package maintainers
would have to change to optimize the spec parse, no central change can
help there.
And yes this has drifted pretty damn far from git merges :)
fedpkg does do a fair amount of python imports. I could probably move
some of those around to be more lazy loaded when a property that
requires them gets accessed, but that makes the code harder to manage.
In practical usage on simple rpms, the amount of time I wait for verrel
to return is so small as to not really interrupt my work flow.
$ time fedpkg verrel
pungi-2.11-2.fc18
real 0m0.563s
user 0m0.437s
sys 0m0.118s
half of a second.
That's the kind of performance I'm seeing too in normal circumstances
(even for the more complex packages like the kernel), and seems
perfectly adequate to me. Uncached performance is what it is but hardly
matters, several seconds worth of python imports per run when cached
would deserve a closer look :)
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: changelog in spec file, was Re: Stop the git abuse
On Thu, May 24, 2012 at 11:02 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: * If a git commit is tagged in a specific way, omit from rpm changelog. What I mean by tagged is a git tag, in form of let's say silentXXX. Where XXX has to be unique, but that can be figured out by fedpkg easily. I'd prefer a SILENT: directly in the commit instead of tags... The only tags that should be necessary are the fXX and elX ones. Is there a sane way to change typos in past changelogs? * a REPLACE$githash: line in a later commit? * Another possibility would be to generate the changelog once for the past commits and add it to the git repository as ChangeLog (IIRC as Adam was talking about it what Mandriva is doing on the initial switch - so just move the automatic changelog generation in the typo case). (I'd highly prefer the later) Greetings, Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On 05/24/2012 11:07 AM, Alexander Larsson wrote: On Thu, 2012-05-24 at 11:22 +0300, Yanko Kaneti wrote: On Thu, 2012-05-24 at 09:35 +0200, Jan Kratochvil wrote: On Thu, 24 May 2012 09:28:16 +0200, Alexander Larsson wrote: However, the whole thing is useless unless we agree that we want to enable this by default. It seems some people like the idea, whereas others disagree that its worth the increased binary size. It doesn't look like either side is gonna be able to convince the other side, so how do we get to a decision here? It is difficult to agree on something when you still have not accepted why some people disagree with it. I do not mind the size, as for example we lose already 5-10% by not using gold (unused + duplicate template methods). I mind that in all aspects better solution is ABRT and we should put more effort to it and not to some temporary poor solutions. (This is very generalized to avoid the discussion again.) And its difficult for me to understand how do you continue to claim in all aspects better when comparing the two, An offline solution that always produces at least something usable to a online one that requires all-star alignment of circumstances to produce the perfect backtrace result. There is no basis for one-or-the-other comparison. IMHO its is a good thing for lightweight, kernel-like userspace backtraces to become widely desseminated across the webs. I obviously agree with this, and disagree with Jan, but I'd like to avoid just repeating the previous discussion. The disagreement seems to be about two things: 1) Any binary size increase is bad (as it affects cd sizes, etc) 2) The results of the MiniDebugInfo is not perfect, and there is a theoretically perfect approach. So we should not spend time/energy/space/bits/whatever on the non-perfect appraoch. However, the perfect approach has other disadvantages due to being online/centralized, so I and others think its worth having both. The increased space is clearly a project global wide question that probably has to be decided by Fesco. The duplication of effort less so IMHO, as different people are doing the work. If we don't do minidebug I will not be spending any resources on the ABRT server anyway. So, not doing minidebug will not affect ABRT positively, and doing it will not affect it negatively (in fact, it might have a slight positive effect as it can use the low quality info when offline). But still, as this is mainly a resource/project management disagreement it might make sense to have Fesco look at it too. In fact it will affect ABRT positively - the calltrace with function names is a pretty good for duplicate checking, so ABRT will be able to find the dupes in already filled bugzilla tickets without requiring the full debuginfo. Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, 2012-05-24 at 11:17 +0200, Jiri Moskovcak wrote: On 05/24/2012 11:07 AM, Alexander Larsson wrote: On Thu, 2012-05-24 at 11:22 +0300, Yanko Kaneti wrote: The duplication of effort less so IMHO, as different people are doing the work. If we don't do minidebug I will not be spending any resources on the ABRT server anyway. So, not doing minidebug will not affect ABRT positively, and doing it will not affect it negatively (in fact, it might have a slight positive effect as it can use the low quality info when offline). But still, as this is mainly a resource/project management disagreement it might make sense to have Fesco look at it too. In fact it will affect ABRT positively - the calltrace with function names is a pretty good for duplicate checking, so ABRT will be able to find the dupes in already filled bugzilla tickets without requiring the full debuginfo. Well, theoretically it could do that by retracing the backtrace on the server. It seems much simpler and more efficient to just do that locally though, but this is partly where the disagreement is. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On 05/24/2012 11:24 AM, Alexander Larsson wrote: On Thu, 2012-05-24 at 11:17 +0200, Jiri Moskovcak wrote: On 05/24/2012 11:07 AM, Alexander Larsson wrote: On Thu, 2012-05-24 at 11:22 +0300, Yanko Kaneti wrote: The duplication of effort less so IMHO, as different people are doing the work. If we don't do minidebug I will not be spending any resources on the ABRT server anyway. So, not doing minidebug will not affect ABRT positively, and doing it will not affect it negatively (in fact, it might have a slight positive effect as it can use the low quality info when offline). But still, as this is mainly a resource/project management disagreement it might make sense to have Fesco look at it too. In fact it will affect ABRT positively - the calltrace with function names is a pretty good for duplicate checking, so ABRT will be able to find the dupes in already filled bugzilla tickets without requiring the full debuginfo. Well, theoretically it could do that by retracing the backtrace on the server. It seems much simpler and more efficient to just do that locally though, but this is partly where the disagreement is. I know we could retrace the calltrace on a server to get the function names, but for the use case we want to use it it's critical to have it fast. And having it stored locally and available at the moment of crash is imho faster than retracing it on a server. I actually don't see a reason (except the space, but the numbers doesn't look so horrible..) why not to have it. No one says it's going to be used in tickets created by ABRT in bugzilla and no one says we're going to force maintainers to work only with these low quality backtraces. ABRT can still require the full backtrace to create a bz ticket and I can easily imagine a situation where knowing just the function name helps me to find a problem. So what's the worry about? Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/24/2012 10:45 AM, drago01 wrote: On Thu, May 24, 2012 at 10:30 AM, Juan Orti Alcaine - Disable the readahead service: systemctl disable systemd-readahead-collect.service systemctl disable systemd-readahead-replay.service systemd should just do that by default (it disables it already when running on a VM). Have you measured the effects of disabling the readahead? In some past measurements readahead gave a slight benefit even with an SSD. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SystemD: When to start service for file system kernel module
On 05/23/2012 09:23 PM, Richard Shaw wrote: Here's my current service file for SPL: Lennart already pointed out a major problem, but here are some remarks about the unit file itself: [Unit] Description=Builds and installs new kmods for SPL Before=local-fs-pre.target When you are writing a unit that is meant to be run during an early phase of boot (before basic.target), you need: DefaultDependencies=no to avoid an ordering cycle. And then you can add a sensible subset of the default dependencies manually: Conflicts=shutdown.target Before=shutdown.target [Service] Type=oneshot In oneshot units it often makes sense to use: RemainAfterExit=yes It depends on whether you want to have the command re-run again or not when a subsequent request to start the unit comes (be it directly via systemctl start, or indirectly via requirement dependencies from other units). ExecStart=-/usr/sbin/akmods --from-init --akmod spl-kmod [Install] WantedBy=single-user.target There's no single-user.target. You probably meant sysinit.target. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/sbin/validate clash with /usr/bin/validate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/24/2012 12:04 AM, Matt Domsch wrote: On Wed, May 23, 2012 at 01:22:35PM -0500, Paul Wouters wrote: I just got caught in having two different validate commands in my path. The /usr/bin/validate version is from the dnssec-tools package. It has a man page and usage info and is a tool to diagnose dnssec lookups. I humbly suggest that the dnssec-tools package should consider changing the name of that executable as well, perhaps dnssec-validate. There are many tools that could claim the term 'validate' for an aspect of what they do. What if 'rpm -V package' had instead been written as 'validate package' ? Or 'gpg -v signaturefile' had been 'validate signaturefile' ? I know, first come first served, but it feels presumptuous to lay claim to a generic action such as this. Thanks, Matt I agree, we should not use a generic name for this function. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk++DpAACgkQrlYvE4MpobNETACgliGzcbjhl9+k0RKayyYvIW71 xx8AnjE2HwJLiBIJ7ukzINnbQHbuQFKs =QVmh -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-17 Branched report: 20120524 changes
Compose started at Thu May 24 08:15:05 UTC 2012 Broken deps for x86_64 -- [LuxRender] LuxRender-blender-0.8.0-13.fc17.x86_64 requires blender(ABI) = 0:2.61 [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires rubygem(fastercsv) aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri [calf] lv2-calf-plugins-0.0.18.6-6.fc17.x86_64 requires lv2core [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-8.fc17.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.2.0.0 [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [lilv] lilv-devel-0.5.0-3.fc17.i686 requires pkgconfig(lv2core) lilv-devel-0.5.0-3.fc17.x86_64 requires pkgconfig(lv2core) [lv2-EQ10Q-plugins] lv2-EQ10Q-plugins-1.0-10.fc17.x86_64 requires lv2core [lv2-abGate] lv2-abGate-1.1.3-4.fc17.x86_64 requires lv2core [lv2-avw-plugins] lv2-avw-plugins-0.0.6-3.fc17.x86_64 requires lv2core [lv2-fil-plugins] lv2-fil-plugins-2.0-5.fc17.x86_64 requires lv2core [lv2-invada-plugins] lv2-invada-plugins-1.2.0-6.fc17.x86_64 requires lv2core [lv2-kn0ck0ut] lv2-kn0ck0ut-1.1-0.4.git60421a3.fc17.x86_64 requires lv2core [lv2-ll-plugins] lv2-ll-plugins-0.2.8-9.fc17.x86_64 requires lv2core [lv2-mdaEPiano] lv2-mdaEPiano-0-0.2.git9db45842.fc17.x86_64 requires lv2core [lv2-swh-plugins] lv2-swh-plugins-1.0.15-7.20110510.9c9935egit.fc17.x86_64 requires lv2core [lv2-vocoder-plugins] lv2-vocoder-plugins-1-4.fc17.x86_64 requires lv2core [lv2-zynadd-plugins] lv2-zynadd-plugins-1-6.fc17.x86_64 requires lv2core [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) [mcollective] mcollective-common-1.3.1-7.fc17.noarch requires ruby(abi) = 0:1.8 [moksha] moksha-0.5.0-5.fc15.noarch requires pyevent [natus] libnatus-V8-0.1.5-2.fc15.x86_64 requires libv8-3.0.0.1.so()(64bit) [ocaml-augeas] ocaml-augeas-0.4-9.fc15.x86_64 requires ocaml(runtime) = 0:3.12.0 [openvrml] libopenvrml-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires java-1.6.0-openjdk(x86-64)
Re: /usr/sbin/validate clash with /usr/bin/validate
On Wed, May 23, 2012 at 02:33:11PM -0400, Adam Jackson wrote:
We're (sort of) trying to phase out /usr/libexec in favor of
%{_libdir}/%{name}/foo, but otherwise that sounds good.
But then the location if a command will depend on whether the system is
a 64 or 32 bit system, which makes it more error prone to write software that
uses such commands on both kind of systems.
Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/sbin/validate clash with /usr/bin/validate
On Wed, 23 May 2012 14:22:35 -0400 (EDT), PW (Paul) wrote: I just got caught in having two different validate commands in my path. The /usr/bin/validate version is from the dnssec-tools package. It has a man page and usage info and is a tool to diagnose dnssec lookups. And there's another /usr/bin/validate in xmlbeans-scripts! https://bugzilla.redhat.com/797793 https://bugzilla.redhat.com/797789 Both without a response so far, however. -- Fedora release 17 (Beefy Miracle) - Linux 3.3.6-3.fc17.x86_64 loadavg: 0.41 0.25 0.15 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, 24 May 2012 11:07:06 +0200, Alexander Larsson wrote: 2) The results of the MiniDebugInfo is not perfect, and there is a theoretically perfect approach. So we should not spend time/energy/space/bits/whatever on the non-perfect appraoch. However, the perfect approach has other disadvantages due to being online/centralized, so I and others think ^^^ / is not + here, other solutions require online connectivity but they do not have to be centralized. its worth having both. There are many ways how to solve this problem, unfortunately nobody knows what is your problem, there are too many close but still different problems in this basket. You have delivered solution without stating the problem first. (1) There are two kinds of developers: (a) PC (instruction) of the crash only (b) full context with parameters, variables and wanting even more. (2) There are also two different kinds of developers: (a) dependency on network services (like ABRT Retrace Server) is OK (b) everything must work with full feature set even offline. (3) And yet more two different kinds of developers: (a) we must not upload anything for security reasons (b) we can freely upload anything because Fedora already has no security. - we already freely download+execute Mozilla binary plugins not reviewed + signed by Fedora Project, 99%(?) people install Flash anyway etc. (4) And yet more two different kinds of developers: (a) desktop ones who have thousands of BZs and ignore any ABRT BZ anyway They are more interested in stats in which parts it crashes the most. (b) at least Tools ones who check each BZ and have more problem that some crashes repeat but they are not reproducible and even rich backtraces in many cases do not contain enough info and it would be best to extend the backtraces/bugreports even more. There are various other solutions still keeping high quality backtraces such as: (x) Already stated fast core files upload to ABRT Retrace Server via gdbserver. (y) With F-18 shorted .debug files http://fedoraproject.org/wiki/Features/DwarfCompressor downloading specific .debug.xz files can be much faster than whole *-debuginfo.rpm. (z) Symbol server for GDB - no need to download full debuginfos, GDB fetches only parts on demand. Maybe other solutions but it depends which of the 16 combinations of the (1), (2), (3) and (4) use cases above you choose. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/sbin/validate clash with /usr/bin/validate
On 5/24/12 7:50 AM, Till Maas wrote:
On Wed, May 23, 2012 at 02:33:11PM -0400, Adam Jackson wrote:
We're (sort of) trying to phase out /usr/libexec in favor of
%{_libdir}/%{name}/foo, but otherwise that sounds good.
But then the location if a command will depend on whether the system is
a 64 or 32 bit system, which makes it more error prone to write software that
uses such commands on both kind of systems.
libexecdir is already a macro expanded at build time. If you were
hardcoding /usr/libexec you were already broken on non-Red-Hat-like
Linuxes. Don't let already being broken be an excuse for continuing to
be broken.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/24/2012 04:45 AM, drago01 wrote: On Thu, May 24, 2012 at 10:30 AM, Juan Orti Alcaine j.orti.alca...@gmail.com wrote: 2012/5/24 Gerry Reno gr...@verizon.net What does Fedora do currently, if anything, to optimize for solid-state drives (SSD). Things like swap and logging can generate a huge number of writes. So I suppose those should maybe be placed on a rotating drive if one is available but if not does Fedora do anything to reduce the amount of writes? Or is everything related to SSD the responsibility of the user? Apart from correctly aligning the partitions, I think there are no more optimizations done by Fedora. I use a SSD and to get the best performance I use ext4 directly on the partitions, without LVM, Luks, RAID, etc. Also, here are a few tips: - Mount options: noatime to reduce writes. discard if your unit supports TRIM Yeah those too make sense (even though realatime should be enough). - Change the default scheduler: I created /etc/rc.d/rc.local with: #!/bin/bash /bin/echo noop /sys/block/sda/queue/scheduler This does not gain you much and hurts in some workloads. - Disable the readahead service: systemctl disable systemd-readahead-collect.service systemctl disable systemd-readahead-replay.service systemd should just do that by default (it disables it already when running on a VM). I also read here: http://ask.fedoraproject.org/question/909/enabling-trimdiscard-on-f16-using-lvm-on-luks about using TRIM with LUKS. Since I'm putting an SSD in my laptop this is important because the laptop drive must be encrypted. So is F17 going to support TRIM w/LUKS automatically? Or do we need to perform some special configuration to get TRIM w/LUKS? (Yes, I understand some attacker might be able to guess my filesystem type due to erased blocks - seems very low risk though). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strategy for packaging an ARM Cortex-M toolchain
Hi Ralf, I wrote: So is it best to attempt to get one arm-binutils package and remove redundancy, or is it going to be more productive to just put up with the redundancy for now? Ralf wrote: No, this will hardly work and would be a nightmare to maintain. I had guessed that binutils didn't care what the ABI was. Maybe I'm wrong about that, or is there something else that I'm missing that'd prevent this from working? Cheers, Rob 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: How to proceed with MiniDebugInfo
On Thu, 2012-05-24 at 14:46 +0200, Jan Kratochvil wrote: On Thu, 24 May 2012 11:07:06 +0200, Alexander Larsson wrote: There are many ways how to solve this problem, unfortunately nobody knows what is your problem, there are too many close but still different problems in this basket. You have delivered solution without stating the problem first. I don't think there has to be a specific problem. In fact, I think Fedora shouldn't really care what *my* problem is. What is interesting is: I have this feature; It has a certain cost (increase in size) and it gives certain features. Is the price worth the features it gives? Now, I don't want to repeat everything said before about what minidebuginfo can do, but I'll give some short examples of things that are nice to have and hard to do well without local debuginfo. * Write backtraces to syslog on coredumps * Allow ABRT to do better duplication matching (the ABRT developers even want minidebuginfo!) * Always get some minimal level of backtrace quality, even for rpms built locally or from other repositories which are not availible on the retrace servers. (Assuming they are built on a F18 or later which has this feature.) * Do system wide profiling and tracing without having to install a lot of debuginfo. * Help developers by always having at least some level of debuginfo, even for e.g. uncommon dependencies that you don't typically have debuginfo for, or when you don't have a network connection to get debuginfo packages. So, does these advantages outweigh the cost? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: changelog in spec file, was Re: Stop the git abuse
On Thu, May 24, 2012 at 11:15:38AM +0200, Thomas Spura wrote: On Thu, May 24, 2012 at 11:02 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: * If a git commit is tagged in a specific way, omit from rpm changelog. What I mean by tagged is a git tag, in form of let's say silentXXX. Where XXX has to be unique, but that can be figured out by fedpkg easily. I'd prefer a SILENT: directly in the commit instead of tags... The only tags that should be necessary are the fXX and elX ones. Is there a sane way to change typos in past changelogs? * a REPLACE$githash: line in a later commit? How about generating a Changelog-file based on all previous commits initially. When doing new commits, it should be updated with the previous commit with a pre-commit hook. The rpm-changelog should then contain this changelog-file + the last commit. Then the changelog-history would contain full commits by default, while still being editable. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Net-OpenSSH
perl-Net-OpenSSH has broken dependencies in the rawhide tree:
On x86_64:
perl-Net-OpenSSH-0.57-3.fc18.noarch requires
openssh-clients(%{__isa_name}-%{__isa_bits})
On i386:
perl-Net-OpenSSH-0.57-3.fc18.noarch requires
openssh-clients(%{__isa_name}-%{__isa_bits})
Please resolve this as soon as possible.
--
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
rawhide report: 20120524 changes
Compose started at Thu May 24 08:15:03 UTC 2012 Broken deps for x86_64 -- [389-admin] 389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48 389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48 389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48 389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit) [389-adminutil] 389-adminutil-1.1.15-2.fc17.i686 requires libicuuc.so.48 389-adminutil-1.1.15-2.fc17.i686 requires libicui18n.so.48 389-adminutil-1.1.15-2.fc17.i686 requires libicudata.so.48 389-adminutil-1.1.15-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-adminutil-1.1.15-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-adminutil-1.1.15-2.fc17.x86_64 requires libicudata.so.48()(64bit) [389-dsgw] 389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit) [aeolus-all] aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-doc = 0:0.4.0-2.fc17 aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-daemons = 0:0.4.0-2.fc17 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri [axis2c] axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32 axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [boost141] boost141-graph-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-graph-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-graph-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-graph-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) boost141-regex-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-regex-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-regex-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-regex-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [evolution-couchdb] evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-cal-1.2.so.15()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-book-1.2.so.13()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libecal-1.2.so.11()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [evolution-rss] 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libedataserverui-3.0.so.1()(64bit) 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [fawkes] fawkes-plugin-xmlrpc-0.4.2-10.fc18.x86_64 requires libxmlrpc_server++.so.7()(64bit) fawkes-plugin-xmlrpc-0.4.2-10.fc18.x86_64 requires libxmlrpc++.so.7()(64bit) [gambas2] gambas2-gb-pdf-2.23.1-10.fc18.x86_64 requires libpoppler.so.19()(64bit) [gambas3] gambas3-gb-pdf-3.1.1-2.fc18.x86_64 requires libpoppler.so.19()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python2-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 [gdb-heap] gdb-heap-0.5-8.fc17.x86_64 requires glibc(x86-64) = 0:2.15 [ghc-warp] ghc-warp-0.4.6.3-3.fc18.i686 requires libHSwai-0.4.3-ghc7.4.1.so ghc-warp-0.4.6.3-3.fc18.i686 requires ghc(wai-0.4.3-876d0504e17291cc228eed88f0ba35c9) ghc-warp-0.4.6.3-3.fc18.x86_64 requires libHSwai-0.4.3-ghc7.4.1.so()(64bit) ghc-warp-0.4.6.3-3.fc18.x86_64 requires ghc(wai-0.4.3-80e159ce6c5c5bb23a495fb1953addc6) ghc-warp-devel-0.4.6.3-3.fc18.i686 requires ghc-devel(wai-0.4.3-876d0504e17291cc228eed88f0ba35c9) ghc-warp-devel-0.4.6.3-3.fc18.x86_64 requires ghc-devel(wai-0.4.3-80e159ce6c5c5bb23a495fb1953addc6) [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) [gnome-python2-desktop] gnome-python2-evolution-2.32.0-9.fc17.x86_64 requires libecal-1.2.so.11()(64bit) [inkscape] inkscape-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit) inkscape-view-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit) [koji] koji-hub-1.6.0-3.fc17.noarch requires mod_python koji-web-1.6.0-3.fc17.noarch requires mod_python [mapnik] mapnik-2.0.0-4.fc17.i686 requires libicuuc.so.48 mapnik-2.0.0-4.fc17.x86_64 requires libicuuc.so.48()(64bit)
Re: How to proceed with MiniDebugInfo
On Thu, 24 May 2012 15:34:28 +0200, Alexander Larsson wrote: I don't think there has to be a specific problem. In fact, I think Fedora shouldn't really care what *my* problem is. What is interesting is: I have this feature; It has a certain cost (increase in size) and it gives certain features. Is the price worth the features it gives? If your feature does not solve any problem it is just a bloat. * Write backtraces to syslog on coredumps backtrace is overloaded here. Minidebuginfo provides only bare unwinds. * Allow ABRT to do better duplication matching (the ABRT developers even want minidebuginfo!) do better is too ambiguous and probably not right. Duplication matching can be always done server-side. Minidebuginfo may give less load for ABRT servers for example, this does not match the do better phrase. * Always get some minimal level of backtrace quality, even for rpms built locally or from other repositories which are not availible on the retrace servers. (Assuming they are built on a F18 or later which has this feature.) I do not limit possible solutions only to retrace servers. Cores can be backtraced even locally with full quality by (y) or (z) from my last mail. * Do system wide profiling and tracing without having to install a lot of debuginfo. But a poor quality again, there won't be line-specific data for example. * Help developers by always having at least some level of debuginfo, even for e.g. uncommon dependencies that you don't typically have debuginfo for, debuginfo-install does everything on its own, user does not have to care. or when you don't have a network connection to get debuginfo packages. This is the only valid point and pre-requisite of all your claims. But I do not find a machine without network connectivity to be useful for anything. So, does these advantages outweigh the cost? Sure in no way. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, May 24, 2012 at 04:19:15PM +0200, Jan Kratochvil wrote: do better is too ambiguous and probably not right. Duplication matching can be always done server-side. Minidebuginfo may give less load for ABRT servers for example, this does not match the do better phrase. And the symbols for the duplication matching aren't as important, it is enough if the reporting client transforms addresses in the unwind address list into build-id + offset form, then it can be matched on the server side too. Only if you want to fuzzy match bugreports from different NVRs, then offsets are not useful and symbol names only sometimes useful. But the build-id + offset form can be transformed into more detailed forms on the server easily. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
jan.kratochvil wrote: If your feature does not solve any problem it is just a bloat. This overstates the case. Alex's proposal clearly solves some problems. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/24/2012 03:20 PM, Gerry Reno wrote: I also read here: http://ask.fedoraproject.org/question/909/enabling-trimdiscard-on-f16-using-lvm-on-luks about using TRIM with LUKS. Since I'm putting an SSD in my laptop this is important because the laptop drive must be encrypted. So is F17 going to support TRIM w/LUKS automatically? Or do we need to perform some special configuration to get TRIM w/LUKS? (Yes, I understand some attacker might be able to guess my filesystem type due to erased blocks - seems very low risk though). To use this feature, you can specify the option allow-discards in /etc/crypttab. You need systemd = 44-11, currently in updates-testing. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, 24 May 2012 16:35:57 +0200, Frank Ch. Eigler wrote: jan.kratochvil wrote: If your feature does not solve any problem it is just a bloat. This overstates the case. Alex's proposal clearly solves some problems. This is just about wording. My reaction was to: I don't think there has to be a specific problem. Alexander talks about Minidebuginfo as about a feature but I find it to be a bugfix category. Specifically to fix what ABRT should have delivered. The primary goal are crash backtraces, tracing is not the Minidebuginfo goal. Tracing is only misused as a way how to push Minidebuginfo through. And bugfix without a problem is just that bloat. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gnome-shell-extension-updater for fedora
Am about to package this: gnome-shell-extension-updater https://github.com/eonpatapon/gnome-shell-extension-updater Just wondering in case if somebody else is working on it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
IMHO administrators would benefit much more from the minidebuginfo feature than developers. The advantage for admins is that for every crash the computer would also give a name of the crash. So it's no longer just httpd: Core dumped., but you get a unique sequence of functions (a name) and you can talk about this particular crash with other admins (it's no longer just our webserver is randomly crashing), and search the Internet for other victims. It would be very cool if the bottom of the stack (last few functions) is printed to the terminal together with the usual Core dumped. message. For developers, it is unappealing to attempt fixing a bug just from an ordered list of function names. Karel Alexander Larsson wrote: Now, I don't want to repeat everything said before about what minidebuginfo can do, but I'll give some short examples of things that are nice to have and hard to do well without local debuginfo. * Write backtraces to syslog on coredumps * Allow ABRT to do better duplication matching (the ABRT developers even want minidebuginfo!) * Always get some minimal level of backtrace quality, even for rpms built locally or from other repositories which are not availible on the retrace servers. (Assuming they are built on a F18 or later which has this feature.) * Do system wide profiling and tracing without having to install a lot of debuginfo. * Help developers by always having at least some level of debuginfo, even for e.g. uncommon dependencies that you don't typically have debuginfo for, or when you don't have a network connection to get debuginfo packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File syntax-0.004.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-syntax: 2bbeda572f7858b8c33bdf3ddf35b390 syntax-0.004.tar.gz -- 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
[perl-syntax] Initial import
commit 689877fd14bae0d68d8e477ea9d5bc88fb9ddbfe
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu May 24 17:11:24 2012 +0200
Initial import
.gitignore |1 +
perl-syntax.spec | 48
sources |1 +
3 files changed, 50 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..e9a2921 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/syntax-0.004.tar.gz
diff --git a/perl-syntax.spec b/perl-syntax.spec
new file mode 100644
index 000..35d2840
--- /dev/null
+++ b/perl-syntax.spec
@@ -0,0 +1,48 @@
+Name: perl-syntax
+Version:0.004
+Release:1%{?dist}
+Summary:Activate syntax extensions
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/syntax/
+Source0:
http://www.cpan.org/authors/id/P/PH/PHAYLON/syntax-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Carp)
+BuildRequires: perl(Data::OptList) = 0.104
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(namespace::clean)
+# Tests
+BuildRequires: perl(FindBin)
+BuildRequires: perl(lib)
+BuildRequires: perl(Test::More) = 0.94
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%description
+This module activates community provided syntax extensions to Perl. You
+pass it a feature name, and optionally a scalar with arguments, and the
+dispatching system will load and install the extension in your package.
+
+%prep
+%setup -q -n syntax-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes LICENSE META.json
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Mon May 21 2012 Jitka Plesnikova jples...@redhat.com 0.004-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..3ea1957 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+2bbeda572f7858b8c33bdf3ddf35b390 syntax-0.004.tar.gz
--
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
File Lexical-SealRequireHints-0.007.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Lexical-SealRequireHints: eff25e457f66a598a3a1631b27ce1b72 Lexical-SealRequireHints-0.007.tar.gz -- 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
[perl-Lexical-SealRequireHints] Initial import
commit 2dc103f1d30ffab2c82065dbd353a57e51f4b06b
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu May 24 17:19:47 2012 +0200
Initial import
.gitignore |1 +
perl-Lexical-SealRequireHints.spec | 59
sources|1 +
3 files changed, 61 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..161e871 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Lexical-SealRequireHints-0.007.tar.gz
diff --git a/perl-Lexical-SealRequireHints.spec
b/perl-Lexical-SealRequireHints.spec
new file mode 100644
index 000..670e665
--- /dev/null
+++ b/perl-Lexical-SealRequireHints.spec
@@ -0,0 +1,59 @@
+Name: perl-Lexical-SealRequireHints
+Version:0.007
+Release:1%{?dist}
+Summary:Prevent leakage of lexical hints
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Lexical-SealRequireHints/
+Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Lexical-SealRequireHints-%{version}.tar.gz
+BuildRequires: perl = 0:5.006
+BuildRequires: perl(Module::Build)
+# Tests
+BuildRequires: perl(Test::More)
+BuildRequires: perl(XSLoader)
+# Optional tests
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(threads)
+BuildRequires: perl(Thread::Semaphore)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Conflicts: perl(B:Hooks::OP::Check) 0.19
+
+%{?perl_default_filter}
+
+%description
+This module works around two historical bugs in Perl's handling of the %^H
+(lexical hints) variable. One bug causes lexical state in one file to leak
+into another that is required/used from it. This bug, [perl #68590], was
+present from Perl 5.6 up to Perl 5.10, fixed in Perl 5.11.0. The second bug
+causes lexical state (normally a blank %^H once the first bug is fixed) to
+leak outwards from utf8.pm, if it is automatically loaded during Unicode
+regular expression matching, into whatever source is compiling at the time
+of the regexp match. This bug, [perl #73174], was present from Perl 5.8.7
+up to Perl 5.11.5, fixed in Perl 5.12.0.
+
+%prep
+%setup -q -n Lexical-SealRequireHints-%{version}
+
+%build
+%{__perl} Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc Changes
+%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/Lexical*
+%{_mandir}/man3/*
+
+%changelog
+* Tue May 22 2012 Jitka Plesnikova jples...@redhat.com 0.007-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..993c4f1 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+eff25e457f66a598a3a1631b27ce1b72 Lexical-SealRequireHints-0.007.tar.gz
--
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: SSD drives
On Thu, 24.05.12 10:30, Juan Orti Alcaine (j.orti.alca...@gmail.com) wrote: - Disable the readahead service: systemctl disable systemd-readahead-collect.service systemctl disable systemd-readahead-replay.service The readahead logic still helps on SSDs actually, simply because SSDs are still a couple of magnitudes slower than RAM. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, 2012-05-24 at 11:06 -0400, Karel Klic wrote: For developers, it is unappealing to attempt fixing a bug just from an ordered list of function names. Sometimes. Other times, it's all I need if I have other data at hand (for example, the git log for the code that's crashing). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On 05/24/2012 07:09 PM, Colin Walters wrote: On Thu, 2012-05-24 at 11:06 -0400, Karel Klic wrote: For developers, it is unappealing to attempt fixing a bug just from an ordered list of function names. Sometimes. Other times, it's all I need if I have other data at hand (for example, the git log for the code that's crashing). Nod. There are always going to be cases where you wont be able to get the perfect backtrace, and a backtrace with nothing but function names is helluva lot more useful than it segfaulted. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/sbin/validate clash with /usr/bin/validate
On Thu, May 24, 2012 at 09:13:51AM -0400, Adam Jackson wrote:
On 5/24/12 7:50 AM, Till Maas wrote:
But then the location if a command will depend on whether the system is
a 64 or 32 bit system, which makes it more error prone to write software that
uses such commands on both kind of systems.
libexecdir is already a macro expanded at build time. If you were
hardcoding /usr/libexec you were already broken on non-Red-Hat-like
Linuxes. Don't let already being broken be an excuse for continuing
to be broken.
Using /usr/libexec in a noarch Fedora package did always work. But if
binaries are in %{_libdir}, a noarch package cannot always contain the
correct path, because the noarch package is the same for both 32 and 64
bit systems. I did not know that debian or other distros do not use
/usr/libexec, but I believe that debian uses /usr/lib for both 32 and 64
bit systems, so using /usr/lib/name/ will work on both archs.
Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, May 24, 2012 at 09:28:16AM +0200, Alexander Larsson wrote: I'm at a loss to how to proceed with the MiniDebugInfo work. I have patches to rpmbuild that creates the compressed minidebuginfo putting them in the main binaries, and I have patches to gdb that reads the compressed debuginfo on demand. However, the whole thing is useless unless we agree that we want to enable this by default. It seems some people like the idea, whereas others disagree that its worth the increased binary size. It doesn't look like either side is gonna be able to convince the other side, so how do we get to a decision here? Just go do it. See who actually shows up to stop you. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, 24 May 2012 19:20:15 +0200, Casey Dahlin wrote: Just go do it. See who actually shows up to stop you. I am sure this is significant enough distro change to require FESCo decision. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/sbin/validate clash with /usr/bin/validate
On 05/24/2012 08:18 PM, Till Maas wrote:
On Thu, May 24, 2012 at 09:13:51AM -0400, Adam Jackson wrote:
On 5/24/12 7:50 AM, Till Maas wrote:
But then the location if a command will depend on whether the system is
a 64 or 32 bit system, which makes it more error prone to write software that
uses such commands on both kind of systems.
libexecdir is already a macro expanded at build time. If you were
hardcoding /usr/libexec you were already broken on non-Red-Hat-like
Linuxes. Don't let already being broken be an excuse for continuing
to be broken.
Using /usr/libexec in a noarch Fedora package did always work. But if
binaries are in %{_libdir}, a noarch package cannot always contain the
correct path, because the noarch package is the same for both 32 and 64
bit systems. I did not know that debian or other distros do not use
/usr/libexec, but I believe that debian uses /usr/lib for both 32 and 64
bit systems, so using /usr/lib/name/ will work on both archs.
Yup. Sure we could flip %_libexecdir to point to /usr/lib (NOT
%{_libdir}) instead of /usr/libexec and rebuild (all) packages, most of
them probably wouldn't notice a thing. But then I also dont really see
the point of turning /usr/lib into even bigger mess than it already is.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/sbin/validate clash with /usr/bin/validate
On Thu, 24 May 2012, Panu Matilainen wrote:
Yup. Sure we could flip %_libexecdir to point to /usr/lib (NOT %{_libdir})
instead of /usr/libexec and rebuild (all) packages, most of them probably
wouldn't notice a thing. But then I also dont really see the point of turning
/usr/lib into even bigger mess than it already is.
Be careful with that. At least for openswan, it would require some
testing before doing that, it might need a change in the spec file.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 17 Final is declared GOLD!
At the Fedora 17 Final Go/No-Go meeting today, the F17 Final Release (RC4) was declared GOLD and ready for GA on May 29, 2012. Thanks to everyone who came today, and to everyone who helped get the Beefy Miracle ready for public devouring. :) Links to meeting minutes and logs follow below. Cheers, -Robyn Meeting Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.html Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.log.html == #fedora-meeting-1: Fedora 17 Final Go NoGo Meeting Round 2 == Meeting started by rbergeron at 17:01:09 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.log.html . Meeting summary --- * Why are we here (rbergero, 17:05:46) * The purpose of this meeting is to determine the shippiness of the final release of F17 (RC4, to be specific). All blocker bugs must be resolved, the test matrices need to be completed, we need to meet final release criteria, QA needs to be on board. :) (rbergero, 17:06:54) * Blocker Bugs (rbergero, 17:07:23) * LINK: http://fedoraproject.org/wiki/Current_Release_Blockers (tflink, 17:08:21) * (824191) nfsiso install hangs during reboot (tflink, 17:09:32) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=824191 (tflink, 17:09:32) * Proposed Blocker, NEW (tflink, 17:09:32) * AGREED: - 824191 - RejectedBlocker - While this is a bug, it doesn't directly violate any of the Fedora 17 release criteria (the install completes, the installed system works). Given that it should only affect a minority of users and could be fixed with an updates.img - it doesn't need to block release. (tflink, 17:18:12) * (824641) kernel 3.3 crashes with blk_dump_rq_flags+ when using a file:/// backend instead of phy:// backend (tflink, 17:18:29) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=824641 (tflink, 17:18:32) * Proposed Blocker, NEW (tflink, 17:18:35) * AGREED: - 824641 - RejectedBlocker - This appears to be a Dom0 issue instead of a DomU issue which does not violate any of the Fedora 17 release criteria. In addition, the use of file:// storage backends is not recommended and phy:// storage backends do not seem affected by this bug (tflink, 17:34:24) * Release Criteria and Test Matrices (rbergero, 17:35:34) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Install (tflink, 17:36:14) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Desktop (tflink, 17:36:28) * 813257 is waived as a blocker as the only options are to wait indefinitely for a fix or drop kdepim entirely; we can't just drop the offending application as it's part of kdepim, which we need (adamw, 17:46:13) * 819275 agreed not to be worthy of blocker consideration as it affects fallback mode only, and fallback mode is niche now (adamw, 18:03:31) * Ship or not to ship, that is the question (rbergero, 18:04:32) * AGREED: We shall ship the Beefy Miracle (aka F17) on Tuesday, May 29 (rbergero, 18:05:56) Meeting ended at 18:07:23 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * adamw (90) * tflink (56) * rbergero (47) * dgilmore (24) * darnok (13) * akshayvyas (7) * nirik (6) * red_alert (5) * zodbot (5) * kparal (3) * mbroyles__ (3) * ADSLLC (1) * rbergeron (1) * satellit_Tris55R (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, May 24, 2012 at 07:27:03PM +0200, Jan Kratochvil wrote: On Thu, 24 May 2012 19:20:15 +0200, Casey Dahlin wrote: Just go do it. See who actually shows up to stop you. I am sure this is significant enough distro change to require FESCo decision. Still cuts his workload down from convincing an open mailing list to convincing 7 people. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, May 24, 2012 at 3:34 PM, Alexander Larsson al...@redhat.com wrote: I don't think there has to be a specific problem. In fact, I think Fedora shouldn't really care what *my* problem is. What is interesting is: I have this feature; It has a certain cost (increase in size) and it gives certain features. Is the price worth the features it gives? It's only this simple if you are adding a new package. Otherwise, there are two more questions: - Is Fedora the right place for the feature? - You contribute the initial code; do the people who would end up maintaining it (if it is someone else than you) accept that code and agree to maintain it? For minidebuginfo, it is a Fedora decision whether to include minidebuginfo in built RPMs - but the inclusion of gdb support is, ideally, up to gdb upstream, or alternatively, up to gdb's package maintainers (in this case, Jan and Sergio). It's not infrequent that a feature happens in Fedora first and is integrated upstream later - but it's not quite the preferred path. Fairly frequently FESCo or FPC agrees to a feature and makes it effectively required for all packages, even if some package maintainers disagree (ideally after gathering input from interested package maintainers first) - but that should IMHO be the case primarily for system-wide features where individual agreement with all affected parties is infeasible. So, where to go from here? For the gdb change, I think the ideal case would be to push the gdb support upstream (I have no idea what upstream thinks, though), second best is to convince Jan and Sergio. Only a third best is asking FESCo to overrule the gdb package maintainers. OTOH, FESCo will probably need to vote on the RPM packaging change in any case, so it would be possible to start with this as well - with the caveat that opposition from gdb package maintainers is an additional risk for the feature and its acceptance. My personal opinion is that this feature is net positive, but not compelling enough to overrule the gdb maintainers and ask them to maintain a Fedora-specific patch they don't like; of course, others on FESCo may, and some probably do, disagree. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 Final is declared GOLD!
whooo! just in time for your status meeting ;-) On 05/24/2012 03:17 PM, Robyn Bergeron wrote: At the Fedora 17 Final Go/No-Go meeting today, the F17 Final Release (RC4) was declared GOLD and ready for GA on May 29, 2012. Thanks to everyone who came today, and to everyone who helped get the Beefy Miracle ready for public devouring. :) Links to meeting minutes and logs follow below. Cheers, -Robyn Meeting Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.html Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.log.html == #fedora-meeting-1: Fedora 17 Final Go NoGo Meeting Round 2 == Meeting started by rbergeron at 17:01:09 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.log.html . Meeting summary --- * Why are we here (rbergero, 17:05:46) * The purpose of this meeting is to determine the shippiness of the final release of F17 (RC4, to be specific). All blocker bugs must be resolved, the test matrices need to be completed, we need to meet final release criteria, QA needs to be on board. :) (rbergero, 17:06:54) * Blocker Bugs (rbergero, 17:07:23) * LINK: http://fedoraproject.org/wiki/Current_Release_Blockers (tflink, 17:08:21) * (824191) nfsiso install hangs during reboot (tflink, 17:09:32) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=824191 (tflink, 17:09:32) * Proposed Blocker, NEW (tflink, 17:09:32) * AGREED: - 824191 - RejectedBlocker - While this is a bug, it doesn't directly violate any of the Fedora 17 release criteria (the install completes, the installed system works). Given that it should only affect a minority of users and could be fixed with an updates.img - it doesn't need to block release. (tflink, 17:18:12) * (824641) kernel 3.3 crashes with blk_dump_rq_flags+ when using a file:/// backend instead of phy:// backend (tflink, 17:18:29) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=824641 (tflink, 17:18:32) * Proposed Blocker, NEW (tflink, 17:18:35) * AGREED: - 824641 - RejectedBlocker - This appears to be a Dom0 issue instead of a DomU issue which does not violate any of the Fedora 17 release criteria. In addition, the use of file:// storage backends is not recommended and phy:// storage backends do not seem affected by this bug (tflink, 17:34:24) * Release Criteria and Test Matrices (rbergero, 17:35:34) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Install (tflink, 17:36:14) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Desktop (tflink, 17:36:28) * 813257 is waived as a blocker as the only options are to wait indefinitely for a fix or drop kdepim entirely; we can't just drop the offending application as it's part of kdepim, which we need (adamw, 17:46:13) * 819275 agreed not to be worthy of blocker consideration as it affects fallback mode only, and fallback mode is niche now (adamw, 18:03:31) * Ship or not to ship, that is the question (rbergero, 18:04:32) * AGREED: We shall ship the Beefy Miracle (aka F17) on Tuesday, May 29 (rbergero, 18:05:56) Meeting ended at 18:07:23 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * adamw (90) * tflink (56) * rbergero (47) * dgilmore (24) * darnok (13) * akshayvyas (7) * nirik (6) * red_alert (5) * zodbot (5) * kparal (3) * mbroyles__ (3) * ADSLLC (1) * rbergeron (1) * satellit_Tris55R (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, 24 May 2012 21:53:48 +0200, Miloslav Trmač wrote: So, where to go from here? For the gdb change, I think the ideal case would be to push the gdb support upstream (I have no idea what upstream thinks, though), second best is to convince Jan and Sergio. I have no problems accepting the patch to Fedora GDB (after some adjustments). I just expect FESCo decision considering its pros and cons distro-wide. I am trying to provide FESCo enough information for the feature as Alexander's presentation of it seems biased to me. Wrt upstreaming the patch to FSF GDB first it can be posted but I would keep it for a release or two only downstream, it is simple enough patch, there may be found some issues with its practical use (if any) etc. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub is a terrible upstream
On 04/23/2012 11:21 AM, Patrick Monnerat wrote: On Mon, 2012-04-23 at 14:27 +0100, Adam Williamson wrote: On Fri, 2012-04-20 at 20:51 -0700, Eric Smith wrote: Corey Richardson wrote: Getting source tarballs from github is a nightmare. See http://lists.fedoraproject.org/pipermail/devel/2011-February/148676.html I noticed putting what you want after .../tarball/ has no effect, thus I have good results by using URLs like: https://github.com/user/app/tarball/gittag/user-app-gittag.tar.gz where user and app identify the repository target and gittag is the hex code of the desired commit. This satisfies rpmbuild and the URL is valid. The downloaded tar contains everything under directory user-app-gittag. Of course, this works as long as the target data (i.e.: repository) lives on github :-/ Patrick It wasn't obvious at first to me but this works with tags not just commit hashes. So if a project tags there version numbers you can do something like: https://github.com/enthought/mayavi/tarball/4.2.0/Mayavi-4.2.0.tar.gz The contents are still in a directory named user-app-hash -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strategy for packaging an ARM Cortex-M toolchain
On 05/24/2012 03:21 PM, Rob Spanton wrote: Hi Ralf, I wrote: So is it best to attempt to get one arm-binutils package and remove redundancy, or is it going to be more productive to just put up with the redundancy for now? Ralf wrote: No, this will hardly work and would be a nightmare to maintain. I had guessed that binutils didn't care what the ABI was. True, AFAICS. However, consider that - binutils is only a comparativly small part of a target's toolchain. - a target's binutils may require target-specific patching. - there can be implicit couplings/incompatibilities between a target's binutils and other components of a cross-toolchain. Maybe I'm wrong about that, or is there something else that I'm missing that'd prevent this from working? You are not necessarily wrong. I agree, using a combined binutils is possibile in many cases (But not always). It's just that, when taking into account that using a combo is close to impossible for other components of a cross-toolchain (esp. GCC), trying use combined binutils is simplier and not worth the effort, IMO. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strategy for packaging an ARM Cortex-M toolchain
On 05/25/2012 05:29 AM, Ralf Corsepius wrote: On 05/24/2012 03:21 PM, Rob Spanton wrote: Hi Ralf, I wrote: So is it best to attempt to get one arm-binutils package and remove redundancy, or is it going to be more productive to just put up with the redundancy for now? Ralf wrote: No, this will hardly work and would be a nightmare to maintain. I had guessed that binutils didn't care what the ABI was. True, AFAICS. However, consider that - binutils is only a comparativly small part of a target's toolchain. - a target's binutils may require target-specific patching. - there can be implicit couplings/incompatibilities between a target's binutils and other components of a cross-toolchain. Maybe I'm wrong about that, or is there something else that I'm missing that'd prevent this from working? You are not necessarily wrong. I agree, using a combined binutils is possibile in many cases (But not always). It's just that, when taking into account that using a combo is close to impossible for other components of a cross-toolchain (esp. GCC), trying use combined binutils is simplier and not worth the effort, IMO. Sorry, typo. This was ment to be 'not trying to use combined binutils..' Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packaging pyroscope
Hey folks, I was wondering if anyone's ever considered packaging pyroscope[1] for Fedora? It adds quite a lot of functionality to rtorrent. I've just started looking into it, and the building looks pretty messy. This is the build script they use[2]. It downloads everything, including rtorrent, and then applies the patches etc. to it. Is this okay? It's going to take some looking into. I ask because it appears to be a good tool and there may be a reason behind why it's still unpackaged. [1] http://code.google.com/p/pyroscope/wiki [2] http://pyroscope.googlecode.com/svn/trunk/pyrocore/docs/rtorrent-extended/build.sh -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ 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: /usr/sbin/validate clash with /usr/bin/validate
On 05/24/2012 09:15 PM, Paul Wouters wrote:
On Thu, 24 May 2012, Panu Matilainen wrote:
Yup. Sure we could flip %_libexecdir to point to /usr/lib (NOT
%{_libdir}) instead of /usr/libexec and rebuild (all) packages, most
of them probably wouldn't notice a thing. But then I also dont really
see the point of turning /usr/lib into even bigger mess than it
already is.
Be careful with that. At least for openswan, it would require some
testing before doing that, it might need a change in the spec file.
Of course such a change would cause some amount of breakage needing
package-level adjustments, no question about it. Mind you I've zero
intention to actually do such a thing, sorry if it came across that way.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 824082] rt3: Multiple security flaws fixed in upstream v3.8.12 and v4.0.6 versions
https://bugzilla.redhat.com/show_bug.cgi?id=824082 --- Comment #3 from Alex Vandiver ale...@bestpractical.com --- To anyone readying a release based on the above, please also note the two follow-up messages addressing problems with sending mail caused by the security patches: http://lists.bestpractical.com/pipermail/rt-announce/2012-May/000205.html http://lists.bestpractical.com/pipermail/rt-announce/2012-May/000206.html As the latter mentions, 3.8.13 should be released in the next couple days to address the issue with mod_perl deployments. - Alex -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 824082] rt3: Multiple security flaws fixed in upstream v3.8.12 and v4.0.6 versions
https://bugzilla.redhat.com/show_bug.cgi?id=824082 --- Comment #4 from Ralf Corsepius rc040...@freenet.de --- Hmm, I am confused about http://lists.bestpractical.com/pipermail/rt-announce/2012-May/000205.html There, you say: RT 3.8.11 and 4.0.5 already require version (FCGI) 0.75 or higher. However, the latest version of FCGI.pm in CPAN is 0.74 as well as does rt-3.8.12/sbin/rt-test-dependencies check for FCGI 0.74? Could you elaborate? -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 824082] rt3: Multiple security flaws fixed in upstream v3.8.12 and v4.0.6 versions
https://bugzilla.redhat.com/show_bug.cgi?id=824082 --- Comment #5 from Alex Vandiver ale...@bestpractical.com --- Gah -- simple typo. Please read that as 0.74, as you confirmed by looking at sbin/rt-test-dependencies.in - Alex -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 824082] rt3: Multiple security flaws fixed in upstream v3.8.12 and v4.0.6 versions
https://bugzilla.redhat.com/show_bug.cgi?id=824082 --- Comment #6 from Ralf Corsepius rc040...@freenet.de --- Thanks for clarifying this. Fedora already ships 0.74, but ... CentOS6 is still at 0.71 ;) -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review: Ticket #383 - usn + mmr = deletions are not replicated
https://fedorahosted.org/389/ticket/383 https://fedorahosted.org/389/attachment/ticket/383/0003-Ticket-383-usn-mmr-deletions-are-not-replicated.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Fedora 17 Final is declared GOLD!
At the Fedora 17 Final Go/No-Go meeting today, the F17 Final Release (RC4) was declared GOLD and ready for GA on May 29, 2012. Thanks to everyone who came today, and to everyone who helped get the Beefy Miracle ready for public devouring. :) Links to meeting minutes and logs follow below. Cheers, -Robyn Meeting Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.html Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.log.html == #fedora-meeting-1: Fedora 17 Final Go NoGo Meeting Round 2 == Meeting started by rbergeron at 17:01:09 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2012-05-24/fedora_17_final_go_nogo_meeting_round_2.2012-05-24-17.01.log.html . Meeting summary --- * Why are we here (rbergero, 17:05:46) * The purpose of this meeting is to determine the shippiness of the final release of F17 (RC4, to be specific). All blocker bugs must be resolved, the test matrices need to be completed, we need to meet final release criteria, QA needs to be on board. :) (rbergero, 17:06:54) * Blocker Bugs (rbergero, 17:07:23) * LINK: http://fedoraproject.org/wiki/Current_Release_Blockers (tflink, 17:08:21) * (824191) nfsiso install hangs during reboot (tflink, 17:09:32) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=824191 (tflink, 17:09:32) * Proposed Blocker, NEW (tflink, 17:09:32) * AGREED: - 824191 - RejectedBlocker - While this is a bug, it doesn't directly violate any of the Fedora 17 release criteria (the install completes, the installed system works). Given that it should only affect a minority of users and could be fixed with an updates.img - it doesn't need to block release. (tflink, 17:18:12) * (824641) kernel 3.3 crashes with blk_dump_rq_flags+ when using a file:/// backend instead of phy:// backend (tflink, 17:18:29) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=824641 (tflink, 17:18:32) * Proposed Blocker, NEW (tflink, 17:18:35) * AGREED: - 824641 - RejectedBlocker - This appears to be a Dom0 issue instead of a DomU issue which does not violate any of the Fedora 17 release criteria. In addition, the use of file:// storage backends is not recommended and phy:// storage backends do not seem affected by this bug (tflink, 17:34:24) * Release Criteria and Test Matrices (rbergero, 17:35:34) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Install (tflink, 17:36:14) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_17_Final_RC4_Desktop (tflink, 17:36:28) * 813257 is waived as a blocker as the only options are to wait indefinitely for a fix or drop kdepim entirely; we can't just drop the offending application as it's part of kdepim, which we need (adamw, 17:46:13) * 819275 agreed not to be worthy of blocker consideration as it affects fallback mode only, and fallback mode is niche now (adamw, 18:03:31) * Ship or not to ship, that is the question (rbergero, 18:04:32) * AGREED: We shall ship the Beefy Miracle (aka F17) on Tuesday, May 29 (rbergero, 18:05:56) Meeting ended at 18:07:23 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * adamw (90) * tflink (56) * rbergero (47) * dgilmore (24) * darnok (13) * akshayvyas (7) * nirik (6) * red_alert (5) * zodbot (5) * kparal (3) * mbroyles__ (3) * ADSLLC (1) * rbergeron (1) * satellit_Tris55R (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
