Re: webkitgtk3 and webkitgtk both installed
On Fri, Mar 16, 2012 at 9:41 PM, Muayyad AlSadi wrote: > hi, > > I made a spin with gimp pre-installed and found that webkitgtk and > webkitgtk3 both installed > > the old webkitgtk is installed only because of gimp > > is there any plan to port gimp to webkitgtk3 It would require the entire app to be ported to gtk3 and I'm not sure of upstream's plan and timeframe to do that but I suspect it's not a small project. You'd likely be better checking the upstream roadmap. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
Once upon a time, Lennart Poettering said: > I think ideally we'd just change the defaults in our kernel so that we > ship with no default sysctl.conf file. Reconfiguring the kernel defaults > all the time out-of-the-box sounds pretty suboptimal to me. It would be better to keep upstream kernel defaults, especially so that someone building their own kernel wouldn't get different settings without any obvious documentation. I don't see a problem with Fedora deciding on different defaults, but it is much more obvious to a system admin if they're in a config file rather than the kernel source. > (That said, if that's really not possible, and we need to keep the file, > we should probaly name it /usr/lib/sysctl.d/00-systemd-default.conf or so) The default file should probably then not be marked as a config file in the RPM (and should be commented as such). There should still be an /etc/sysctl.conf with just comments pointing to the various places. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2012-03-19 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-03-19 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time once more. We're deep into Beta cycle now, and we have Test Days to report also. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20120319 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 17 Beta status 3. Test Day report 4. Upcoming QA events 5. AutoQA update 6. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Qt compiler tool names
On Sat, Mar 17, 2012 at 12:07 AM, Rex Dieter wrote: > Aaron Faanes wrote: > >>> We used the -qt4 postfix (which is a common practice among most distros >>> these days) to allow for a parallel-installable qt3. >>> >> >> Ah, I figured it was something like that. I couldn't find it using the >> following: >> >> $ yum provides '*/bin/*-qt3' >> Loaded plugins: auto-update-debuginfo, langpacks, presto, >> refresh-packagekit No Matches found >> $ >> >> So I guess the qt3 stuff lives in a repo I no longer have access to, >> perhaps? > > That the qt4 variants use a postfix doesn't imply that qt3 does too (it > currently does not, due to it's legacy heritage, for better or worse). > So is it perhaps time to rename the qt3 stuff to -qt3 and make room for the qt4 stuff? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Sat, 2012-03-17 at 00:17 -0400, Gerry Reno wrote: > On 03/16/2012 06:30 PM, Adam Williamson wrote: > > On Fri, 2012-03-16 at 23:18 +0100, Kevin Kofler wrote: > > > >> Adam Williamson wrote: > >> > >>> It's a fairly well-known issue that you can't build the NVIDIA driver > >>> against a debug kernel without tweaking something somewhere. It works > >>> fine if you use a non-debug kernel. > >>> > >> Not really: https://bugzilla.redhat.com/show_bug.cgi?id=751891 > >> Anything dlopening libGL directly or indirectly can still cause glibc > >> errors. Neither glibc's nor nvidia's fix solved that issue for everyone. > >> We > >> still get duplicates of this bug reported regularly. > >> > > Oh, yeah, that one. I *think* the issue the OP was referring to was the > > well-known one with getting it to even build against a debug kernel, > > though. It complains about the license on some symbols or other. > > > > And for anyone interested in the history of 3D graphics hardware here's > an article with a lot of good hardware photos and info: > > > http://www.maximumpc.com/article/features/graphics_extravaganza_ultimate_gpu_retrospective/ > > It's a couple years old but still good. Hey, that's pretty good. Don't see any big mistakes, and they even got the i740 in there. Solid 8 or 9 out of 10 I'd say. I've owned far too many of those... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On 03/16/2012 06:30 PM, Adam Williamson wrote: > On Fri, 2012-03-16 at 23:18 +0100, Kevin Kofler wrote: > >> Adam Williamson wrote: >> >>> It's a fairly well-known issue that you can't build the NVIDIA driver >>> against a debug kernel without tweaking something somewhere. It works >>> fine if you use a non-debug kernel. >>> >> Not really: https://bugzilla.redhat.com/show_bug.cgi?id=751891 >> Anything dlopening libGL directly or indirectly can still cause glibc >> errors. Neither glibc's nor nvidia's fix solved that issue for everyone. We >> still get duplicates of this bug reported regularly. >> > Oh, yeah, that one. I *think* the issue the OP was referring to was the > well-known one with getting it to even build against a debug kernel, > though. It complains about the license on some symbols or other. > And for anyone interested in the history of 3D graphics hardware here's an article with a lot of good hardware photos and info: http://www.maximumpc.com/article/features/graphics_extravaganza_ultimate_gpu_retrospective/ It's a couple years old but still good. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Qt compiler tool names
Aaron Faanes wrote: >> We used the -qt4 postfix (which is a common practice among most distros >> these days) to allow for a parallel-installable qt3. >> > > Ah, I figured it was something like that. I couldn't find it using the > following: > > $ yum provides '*/bin/*-qt3' > Loaded plugins: auto-update-debuginfo, langpacks, presto, > refresh-packagekit No Matches found > $ > > So I guess the qt3 stuff lives in a repo I no longer have access to, > perhaps? That the qt4 variants use a postfix doesn't imply that qt3 does too (it currently does not, due to it's legacy heritage, for better or worse). -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Qt compiler tool names
On Fri, Mar 16, 2012 at 10:35 PM, Rex Dieter wrote: > Aaron Faanes wrote: > > > I was wondering why Qt compiler tools (qmake, moc, uic, etc.) are > > installed with each name suffixed with -qt4 (qmake-qt4, moc-qt4). This > > diverges from how upstream names its tools (specifically, without qt4 > > added), so it caused me a little confusion when these tools appeared to > be > > missing. > > > > My solution was to add /usr/lib/qt4/bin to my PATH since this directory > > contains symlinks that use upstream's name. However, I would prefer the > > tools to be installed in /usr/bin without -qt4 appended. Is there a > reason > > why this shouldn't be done? > > We used the -qt4 postfix (which is a common practice among most distros > these days) to allow for a parallel-installable qt3. > Ah, I figured it was something like that. I couldn't find it using the following: $ yum provides '*/bin/*-qt3' Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit No Matches found $ So I guess the qt3 stuff lives in a repo I no longer have access to, perhaps? At any rate, the GNU Autoconf Archive has a AX_HAVE_QT macro that wasn't aware of the -qt4 suffix, along with some other Fedora-specific deviations. I'm going to submit a couple patches to that project in order to make their macro work cleanly on Fedora, especially since things like -qt4 are common practice. Thanks for the response! > > -- rex > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Aaron Faanes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Qt compiler tool names
Aaron Faanes wrote: > I was wondering why Qt compiler tools (qmake, moc, uic, etc.) are > installed with each name suffixed with -qt4 (qmake-qt4, moc-qt4). This > diverges from how upstream names its tools (specifically, without qt4 > added), so it caused me a little confusion when these tools appeared to be > missing. > > My solution was to add /usr/lib/qt4/bin to my PATH since this directory > contains symlinks that use upstream's name. However, I would prefer the > tools to be installed in /usr/bin without -qt4 appended. Is there a reason > why this shouldn't be done? We used the -qt4 postfix (which is a common practice among most distros these days) to allow for a parallel-installable qt3. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora is featuring on GSoC 2012
Buddhike - | I am delighted to announce that the Fedora Project has been accepted | for the GSoC 2012 program[0]. | This would be the 7th time where the Fedora project represents the | program since 2005. | | The students' application procedure and other relevant information | will be published soon. If you are interested in | joining with the Fedora project as a student or a mentor please | explore following URLs. | | First of all subscribe for the summer-coding mailing list [1] and | explore the Idea list [2], feel free to contact us for more | information. | | [0] http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2012 | | [1] https://admin.fedoraproject.org/mailman/listinfo/summer-coding | | [2] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012 This is really wonderful. Thanks for stepping up to the task. The hard work starts now. Harish | -- | Regards, | Buddhike Chandradeepa Kurera(bckurera) | Fedora Ambassador Sri Lanka | Event Liaison - Design Team | | Email: bckur...@fedoraproject.org | IRC: bckurera | -- | devel mailing list | devel@lists.fedoraproject.org | https://admin.fedoraproject.org/mailman/listinfo/devel -- Harish Pillay 9v1hp hpil...@redhat.com +65.9636.9253 gpg id: 746809E3 pgpFpELBs9EtF.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Qt compiler tool names
I was wondering why Qt compiler tools (qmake, moc, uic, etc.) are installed with each name suffixed with -qt4 (qmake-qt4, moc-qt4). This diverges from how upstream names its tools (specifically, without qt4 added), so it caused me a little confusion when these tools appeared to be missing. My solution was to add /usr/lib/qt4/bin to my PATH since this directory contains symlinks that use upstream's name. However, I would prefer the tools to be installed in /usr/bin without -qt4 appended. Is there a reason why this shouldn't be done? -- Aaron Faanes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 2012-03-15 Dan Williams wrote: > The only effect this checking will have is to change NetworkManager's > state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It > doesn't do anything odd like disconnect and retry some other connection, > which wouldn't make much sense. It just changes some state which apps > can use to figure out whether they'd connect to say your IRC server or > your email or whatever automatically. Hi Dan, I suggest that is something the application should determine, not NetworkManager. Take the case where a ISP loses international connectivity, then a NetworkManager-informed application won't connect to the in-country ISP's IRC/e-mail/... server even though those servers are available. Thus connectivity detection worsens a partial loss of connectivity into a full loss of connectivity. The app has to be able to handle no connectivity anyway: just because Network Manager can HTTP GET the URI doesn't mean that IRC works. For example, a corporate firewall could allow HTTP but block IRC. Both the end-to-end argument and occam's razor argue for the application gracefully handling no connectivity. The current situation is that many apps don't handle a lack of connectivity with grace. But I suggest that this isn't NetworkManager's problem to solve. Even the current situation isn't great. NetworkManager shouldn't be telling applications that the network is available. That DBUS message should be triggered by the insertion into the main forwarding table of a default route. Then any source of global connectivity will set the app connecting (NM, NM work alikes, "ip route add", ospfd, tunnels, etc). Best wishes, Glen PS: I really don't understand the operation of dnssec-triggerd. The paths for HTTP and DNS traffic through an enterprise network can be very different so testing one protocol doesn't say a huge amount about the availability of the other protocol. But then I don't even understand the desirability of that program: allowing an external event (eg an access list on a router or a DoS attack) to trigger a reconfiguration from a DNSSEC-validating to a non-validating configuration seems more of a security bug than a feature. But I'm likely missing something here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, 16.03.12 14:40, Michal Hlavinka (mhlav...@redhat.com) wrote: > On 03/16/2012 02:28 PM, Lennart Poettering wrote: > >On Fri, 16.03.12 14:54, Muayyad AlSadi (als...@gmail.com) wrote: > > > >>but this does not make sense > >> > >>the idea behind all .d is to allow packages to provide default (either > >>kernel defaults or distro defaults) > >>because the other choice is to use %post and sed > > > >>eg. let's say I made a firewall package that needs to enable > >>forwarding, it would put it in a sysctl.d > > > >If a package places a sysctl file in /etc/sysctl.d/ then you can > >override it with /etc/sysctl.conf, hence everything is as it should, no? > >This whole logic is designed so that the admin's configuration always > >takes precedence over vendor configuration. Which is the right thing to > >do. > > > >That said, note that it's probably a good idea if packages stick their > >sysctl files in /usr/lib/sysctl.d instead, so that that users can use > >/etc/sysctl.d/ to override that. /etc/sysctl.conf is read mostly for > >compatibility reasons only. > > As I understand it, Muayyad has different problem. Right now, the > /etc/sysctl.conf we ship is not empty. It has several values set, > one of them is sysrq=0 he used in his example. No one set this is > value, it's just default value and yet, no package can change it by > placing its file in /etc/sysctl.d This would work only if > sysctl.conf is empty and all default configuration is moved to > /etc/sysctl.d/00-systemdefault.conf Ah, hmm, I wasn't aware of that. I think ideally we'd just change the defaults in our kernel so that we ship with no default sysctl.conf file. Reconfiguring the kernel defaults all the time out-of-the-box sounds pretty suboptimal to me. (That said, if that's really not possible, and we need to keep the file, we should probaly name it /usr/lib/sysctl.d/00-systemd-default.conf or so) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
On 03/16/2012 10:06 PM, Kevin Kofler wrote: David Tardon wrote: How do we prevent inexperienced testers from giving undeserved karma and thus causing an update to be automatically pushed to stable? One has to fulfil certain requirements before one becomes a packager. But anyone with FAS account can give karma to an update... +1, the current policy is really flawed, we trust any idiot with a FAS account more than our sponsored packagers (and even our carefully vetted provenpackagers). Kevin Kofler But this policy also prevents the misuse of power, which is also a good thing I think. And there needs to be more than one "idiot" to make any changes to the update which is not the case of packagers or even provenpackagers. Which I think is really helpful since in most cases those people are also only humans which could make mistakes. I think this policy helps to prevent updates which break a lot of stuff when pushed to stable, it also provides a nice and quicker way of first contact to check if there are some issues with an update. Johannes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Fri, 2012-03-16 at 23:18 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > It's a fairly well-known issue that you can't build the NVIDIA driver > > against a debug kernel without tweaking something somewhere. It works > > fine if you use a non-debug kernel. > > Not really: https://bugzilla.redhat.com/show_bug.cgi?id=751891 > Anything dlopening libGL directly or indirectly can still cause glibc > errors. Neither glibc's nor nvidia's fix solved that issue for everyone. We > still get duplicates of this bug reported regularly. Oh, yeah, that one. I *think* the issue the OP was referring to was the well-known one with getting it to even build against a debug kernel, though. It complains about the license on some symbols or other. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
Reindl Harald wrote: > yes, but the really bug is that "sysctl.conf" is not shipped empty > > it should be the global place where the admin can override ANY setting > from any other file/package and so it is correct to apply systcl.conf > as last item - as said only if it would be shipped empty +1, Kay Sievers also says that: https://bugzilla.redhat.com/show_bug.cgi?id=760254#c2 so can we get that implemented? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
Adam Williamson wrote: > It's a fairly well-known issue that you can't build the NVIDIA driver > against a debug kernel without tweaking something somewhere. It works > fine if you use a non-debug kernel. Not really: https://bugzilla.redhat.com/show_bug.cgi?id=751891 Anything dlopening libGL directly or indirectly can still cause glibc errors. Neither glibc's nor nvidia's fix solved that issue for everyone. We still get duplicates of this bug reported regularly. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
Adam Williamson wrote: > That might be an appropriate time to try and work some kind of > connection between Bugzilla and Bodhi. But I still think it might be > very difficult to do; it's very difficult to parse a freeform Bugzilla > comment That's why it's best to leave this to a human! Software is not the universal solution to every problem in the world. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
David Tardon wrote: > How do we prevent inexperienced testers from giving undeserved karma and > thus causing an update to be automatically pushed to stable? > > One has to fulfil certain requirements before one becomes a packager. > But anyone with FAS account can give karma to an update... +1, the current policy is really flawed, we trust any idiot with a FAS account more than our sponsored packagers (and even our carefully vetted provenpackagers). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
> > > If 00-foo sets something to value A, and 99-bar sets it to B, > and B < A, foo may not function correctly. > > This isn't an ordering problem, it's an exclusivity problem, because > sysctls are system-wide, not per-package. > this applies to every thing, if 00-foo sets foo as the best font for "Arial" and 01-monkey set's a monkey as the best font for "Arial" then only one will be chosen same for /etc/profile.d/ if we have 00-ps1.sh and 01-ps1.sh both set $PS1, of course one of them would work -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
webkitgtk3 and webkitgtk both installed
hi, I made a spin with gimp pre-installed and found that webkitgtk and webkitgtk3 both installed the old webkitgtk is installed only because of gimp is there any plan to port gimp to webkitgtk3 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Fri, 2012-03-16 at 17:01 -0400, Gerry Reno wrote: > On 03/16/2012 02:48 PM, Adam Williamson wrote: > > On Fri, 2012-03-16 at 14:31 -0400, Gerry Reno wrote: > > > >> On 03/15/2012 10:46 PM, Gerry Reno wrote: > >> > >>> On 03/15/2012 10:30 PM, Adam Williamson wrote: > >>> > >>> > On Thu, 2012-03-15 at 22:22 -0400, Gerry Reno wrote: > > > > > Yeah, installed the beta and I'm still having the exact same problem. > > > > Graphics is Geforce FX 5600 > > > > > > > Ah. Then that'll be https://bugzilla.redhat.com/show_bug.cgi?id=745202 . > > > > >>> Looks like it. > >>> > >>> My screen issues are a little bit different but I think it's the same > >>> underlying problem: driver issues. > >>> > >>> > >>> > >>> > >> I just saw comment 47 in the bug. > >> > >> I'm not sure I understand the part about workaround with blacklisting. > >> > >> At no time do I have a working Terminal after reboot. And what exactly > >> ends up being blacklisted? I thought only drivers got blacklisted. How > >> do you blacklist a card? Does someone have an example? > >> > > That's more a discussion for how we as the Fedora (and upstream GNOME) > > devs can fix the problem than how you as a user can fix it. > > > > The 'blacklist' we're talking about is GNOME's blacklist of cards that > > have 3D-accelerated drivers that seem to satisfy all the Shell > > requirements, but are in fact known to be incapable of satisfactorily > > rendering Shell. It's located > > at /usr/share/gnome-session/hardware-compatibility (in F17, anyway, I > > think it may have been different in F16). It blacklists based on the > > Mesa renderer string; the level of granularity it's capable of depends > > on how each Mesa driver decides to write its renderer string. For the > > main drivers (Intel, Radeon, Nouveau) it's possible to achieve pretty > > much GPU-level granularity. > > > > Adam, thanks for that clarification. > > Also, can you boil this down a little for those of us with nVidia FX > NV3/NV4 graphics? > > What can we expect for F17 in the way of supporting our nvidia graphics > cards? > > Just some type of non-accelerated solution? > > Or will there be a driver written that will properly support these > nVidia cards? With the blacklist in place, you'd get the fallback mode. Right now, anyway. It may change so that you wind up with software rendering of the Shell. Ben is working on a rewrite of the driver for these cards; what's unclear is whether it will be done in reasonable time to get merged into F17. If it does, we'll see if we can merge it in and remove the blacklist. If it doesn't, you'll have the blacklisted behaviour with the released F17. > And I went looking into nVidia non-free driver but it appears there is a > problem with glibc conflict that prevents use of these drivers. Any > comment on that situation? It's a fairly well-known issue that you can't build the NVIDIA driver against a debug kernel without tweaking something somewhere. It works fine if you use a non-debug kernel. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On 03/16/2012 02:48 PM, Adam Williamson wrote: > On Fri, 2012-03-16 at 14:31 -0400, Gerry Reno wrote: > >> On 03/15/2012 10:46 PM, Gerry Reno wrote: >> >>> On 03/15/2012 10:30 PM, Adam Williamson wrote: >>> >>> On Thu, 2012-03-15 at 22:22 -0400, Gerry Reno wrote: > Yeah, installed the beta and I'm still having the exact same problem. > > Graphics is Geforce FX 5600 > > > Ah. Then that'll be https://bugzilla.redhat.com/show_bug.cgi?id=745202 . >>> Looks like it. >>> >>> My screen issues are a little bit different but I think it's the same >>> underlying problem: driver issues. >>> >>> >>> >>> >> I just saw comment 47 in the bug. >> >> I'm not sure I understand the part about workaround with blacklisting. >> >> At no time do I have a working Terminal after reboot. And what exactly >> ends up being blacklisted? I thought only drivers got blacklisted. How >> do you blacklist a card? Does someone have an example? >> > That's more a discussion for how we as the Fedora (and upstream GNOME) > devs can fix the problem than how you as a user can fix it. > > The 'blacklist' we're talking about is GNOME's blacklist of cards that > have 3D-accelerated drivers that seem to satisfy all the Shell > requirements, but are in fact known to be incapable of satisfactorily > rendering Shell. It's located > at /usr/share/gnome-session/hardware-compatibility (in F17, anyway, I > think it may have been different in F16). It blacklists based on the > Mesa renderer string; the level of granularity it's capable of depends > on how each Mesa driver decides to write its renderer string. For the > main drivers (Intel, Radeon, Nouveau) it's possible to achieve pretty > much GPU-level granularity. > Adam, thanks for that clarification. Also, can you boil this down a little for those of us with nVidia FX NV3/NV4 graphics? What can we expect for F17 in the way of supporting our nvidia graphics cards? Just some type of non-accelerated solution? Or will there be a driver written that will properly support these nVidia cards? And I went looking into nVidia non-free driver but it appears there is a problem with glibc conflict that prevents use of these drivers. Any comment on that situation? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, Mar 16, 2012 at 09:42:50PM +0200, Muayyad AlSadi wrote: > > What happens if two packages want to set a sysctl to different values ? > > that's why they are prefixed with numbers, the higher number will take > effect > eg. 99-foobar.conf > > sometimes we have conventions for number ranges like this > > http://fedoraproject.org/wiki/Fontconfig_packaging_tips#Choosing_a_ruleset_numeral_prefix > > 50 User overrides > 51 Local system overrides > ... But for a system wide change, that's insufficient. If 00-foo sets something to value A, and 99-bar sets it to B, and B < A, foo may not function correctly. This isn't an ordering problem, it's an exclusivity problem, because sysctls are system-wide, not per-package. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
On Fri, Mar 16, 2012 at 09:29:33AM +0100, Emanuel Rietveld wrote: > On 03/15/2012 08:24 PM, Kevin Kofler wrote: > >Adam Williamson wrote: > >>Luke Macken does Bodhi. It certainly sounds non-trivial to me, for a > >>start, Bodhi uses FAS and Bugzilla does not. > > > >It would be trivial if these decisions would be made by a human who is CCed > >on both (i.e. the maintainer of the package) rather than by software. > > > > Kevin Kofler > > > > Policy always hinders the most talented workers (in this case, the > best package maintainers). The purpose of policy is to limit the > damage a less experienced package maintainer can do. > > How do we prevent an inexperienced package maintainer from > prematurely pushing updates to stable? How do we prevent inexperienced testers from giving undeserved karma and thus causing an update to be automatically pushed to stable? One has to fulfil certain requirements before one becomes a packager. But anyone with FAS account can give karma to an update... D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?
On Fri, Mar 16, 2012 at 1:57 AM, Jan Kratochvil wrote: >> And both machines pass rpm -Va just fine. So the binaries should, um, >> be the same. > + >> It is a core from yesterday, > > There can be difference one of the machines has the files prelink-ed while the > other one does not. prelink runs nightly (/etc/cron.daily/prelink). But it Thanks! Prelink is not involved -- I doublechecked. In OLPC builds, we currently don't prelink due to http://dev.laptop.org/ticket/10898 , we just don't install prelink and don't run it during OS image creation. Even back then when we did, we disabled the cronjob :-) > should be already fixed in your GDB version gdb-7.2-52.fc14, You got that one right :-) > If it helps please contact me off-list, with your disk image. It assumes the > system generating the core file was not prelinked. Uploading at http://dev.laptop.org/~martin/os5rw-brokenimg/Sandisk_1200908562DEN.img Bear in mind - that'll contain 2 partitions. The 2nd partition is / but our initrd mounts it, and then chroots into a subdirectory. So when you mount it, you'll want too look into /versions/run/5/ (WTF is this? Root FS "snapshots" via hardlinked trees. Until we have btrfs running on these puppies, it's the best update fail-proof mechanism we have.) > That missing file: > Missing separate debuginfo for > Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install > /usr/lib/debug/.build-id/63/420e48a2edbae61166c708ebd2ff1a5aed1054 > > is probably for kernel vDSO (as its name is empty), therefore kernel rpm. Argh, that could be. But our kernel is a custom built rpm, and we don't build -debuginfo. Here, have a fistful of my freshly-torn-out hair. Now, at the time of this segfault, the dmesg reports a segfault in python2.7, inside calls to glib... (1) why are we then in the kernel and (2) why isn't gdb telling us anything about the python/glib part of the callstack? still confused - martin PS: On a different investigation track we think there may be some subtle/odd disk corruption that _passes_ rpm -Va and our own olpc-contents-verify, yet strikes at runtime. Could a subtly corrupt binary (ie: vmlinuz) lead here? -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
> What happens if two packages want to set a sysctl to different values ? that's why they are prefixed with numbers, the higher number will take effect eg. 99-foobar.conf sometimes we have conventions for number ranges like this http://fedoraproject.org/wiki/Fontconfig_packaging_tips#Choosing_a_ruleset_numeral_prefix 50 User overrides 51 Local system overrides ... On Fri, Mar 16, 2012 at 8:56 PM, Chris Adams wrote: > Once upon a time, Chris Adams said: > > Once upon a time, Matthew Garrett said: > > > On Fri, Mar 16, 2012 at 10:57:13AM -0500, Chris Adams wrote: > > > > Once upon a time, Matthew Garrett said: > > > > > No package should be automatically changing the sysrq policy. > > > > > > > > Why not? > > > > > > > > For example, I use a commercial backup program that makes extensive > use > > > > of IPC and needs the msgmni and msgmnb limits raised beyond the > default > > > > values. Why shouldn't they be able to include that change in their > RPM? > > > > > > Where did I say they shouldn't? > > > > You mean other than the quoted line? > > My appologies; I misread "sysrq" as "sysctl". > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Petr Pisar > How does fd00::/16 differes from 10.0.0.0/8? Why getting site scope > address in IPv4 is Ok, while getting such address in IPv6 is considered > as failure? Just a little comment regarding the terminology used here. The terms "global", "site", and "link" scope have very specific and defined meanings in IPv6. If you run "/sbin/ip -6 address list" you will see that all the addresses returned include their scope. You can also select addresses by their scope (e.g. do stuff like "/sbin/ip -6 address flush scope global"). ULAs, fd00::/7, explicitly have a global scope. This is because their reachability is not restricted to a single organisation or site - one of the main features of ULAs compared to site-scoped addresses are that even though they won't be seen on the public internet, two separate organisations can very well connect using VPNs or private interconnects and use their own separate ULA prefixes to communicate. In other words, the scope of ULA addresses are defined by the routing and network topology around them, not by the actual addresses themselves. Look at RFC 4193 for more details (in particular section 3.3). This means that if NM's connectivity check were to report that it had "site" connectivity when only having ULA addresses configured, it would actually be incorrect as far as IPv6 terminology goes. It would be more correct to say "not internet" or something along those lines. Best regards, -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora is featuring on GSoC 2012
Hello, I am delighted to announce that the Fedora Project has been accepted for the GSoC 2012 program[0]. This would be the 7th time where the Fedora project represents the program since 2005. The students' application procedure and other relevant information will be published soon. If you are interested in joining with the Fedora project as a student or a mentor please explore following URLs. First of all subscribe for the summer-coding mailing list [1] and explore the Idea list [2], feel free to contact us for more information. [0] http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2012 [1] https://admin.fedoraproject.org/mailman/listinfo/summer-coding [2] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012 -- Regards, Buddhike Chandradeepa Kurera(bckurera) Fedora Ambassador Sri Lanka Event Liaison - Design Team Email: bckur...@fedoraproject.org | IRC: bckurera -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
Hi Dan, * Dan Williams > On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote: > >> That is true, however, if IPv6 completes first, and IPv4 (still running >> in the background) eventually ends up failing, the *entire connection* >> will be torn down - including the perfectly working IPv6 connectivity. >> So the successfully connected state only lasts for about 20 seconds. > > I've gone back and forth on this last week; since it changes the > default, it would break the case where somebody depends on the current > behavior, ie that by default IPv4 may not fail. After this patch is > applied, a network where IPv6 connectivity is available but broken (or > where the router sends RAs with private prefixes like fdxx::) and IPv4 > is for some reason also broken, will make NM show "connected" when in > fact we aren't really. The new connectivity detection will help that > somewhat, but we haven't enabled it by default yet for a few reasons. > > I ran into a network when testing this that caused me to think harder > about this patch. It's an Actiontec router attached to Comcast (I > think) but has no upstream IPv6 connectivity. It sends RAs for the > fdxx:: address space and NM dutifully picks that up. So now we've got > IPv6 connectivity to a "private" prefix that's not routable. If, in > this case, the router's DHCP server died, which sometimes happens on > crappy consumer hardware, an upgraded NM would report connected while > old NMs would fail the connection. > > Whether we care enough about this regression (if you want to call it > that) versus enabling default IPv6 connectivity I don't know, I tend to > think we suck up the regression. But I'm still interested in the > failure cases. So what you have here is a double failure, of sorts. First, your DHCPv4 service is broken, and second, your IPv6 service is broken too, but in a way that doesn't stop RAs. You'd like the connection activation to fail in this case. But what do you really accomplish? The systray icon will say "not connected", which may be somewhat useful, but on the other hand, by allowing it to say "connected" instead, the user is really not any worse off - his browser (or whatever application will give him error messages in both cases, and he won't get to do what he wants to do. Besides, conceptually, this error isn't any different from another one that doesn't involve IPv6 at all. Let's say that the DHCPv4 server in your home gateway router works beautifully, but that its upstream DOCSIS/DSL/fibre/whatever link doesn't. (Having myself been on DSL for a number of years, I'll be damned if this is not something that happens *way* more frequently than the scenario you outlined above.) If you want to be consistent in not activating the network connection when internet connectivity doesn't work, you'd have to make sure the connection fails in this case too, right? But you don't, you allow the connection to succeed without the internet connectivity working. Which leaves the user in the exact same place as the guy behind the Actiontec. It's been like this for, like, forever. And somehow, the sky hasn't fallen yet. :-) However, if you turn it around, the guy behind the Actiontec with the defective DHCPv4 server might actually have working IPv6 connectivity, or at least he will have soon - Comcast is one of the leading ISPs in the world when it comes to IPv6 deployment. Do you really want to leave him without *any* connectivity in this case, or is it better to leave IPv4 failed but IPv6 working? Remember, with the entire connection failed, he can't get anywhere at all. With IPv6 still working, he'll be able to get to Google and try to find out what is going on, he'll probably be able to get to Comcast's customer portal to request assistance, or simply to hit Facebook to kill some time. That has got to be much better than having no connectivity at all, agreed? And, finally, that IPv6-only networks are a perfectly valid configuration is undisputable. Requiring IPv4 breaks those, too. The way I see it, what you gain by not allowing IPv4 to fail is providing the user with more clear error message in the case of a very narrow failure scenario. You don't actually fix or work around the problem in any way. Furthermore, you break other valid configurations, and aggravate other narrow failure scenarios. It's clearly not worth it, in my opinion. I know my patch is already in NM git, so I just wanted to send you this message mostly so you can sleep easy at night - convince you it was the right thing to do. :-) Thank you again! > Next up, since AFAIK fdxx:: is a non-routable private network (like 10/8 > right?) should NM say that we're only connected to a site-local network > here? That would at least help the situation above, and indicate that > something went wrong instead of NM saying we're connected to the > internet and nothing working. Yes and no. On their own, Unique Local Addresses (fd00::/7) addresses needs NAT66, proxies, or someth
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
Once upon a time, Chris Adams said: > Once upon a time, Matthew Garrett said: > > On Fri, Mar 16, 2012 at 10:57:13AM -0500, Chris Adams wrote: > > > Once upon a time, Matthew Garrett said: > > > > No package should be automatically changing the sysrq policy. > > > > > > Why not? > > > > > > For example, I use a commercial backup program that makes extensive use > > > of IPC and needs the msgmni and msgmnb limits raised beyond the default > > > values. Why shouldn't they be able to include that change in their RPM? > > > > Where did I say they shouldn't? > > You mean other than the quoted line? My appologies; I misread "sysrq" as "sysctl". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
Once upon a time, Dave Jones said: > On Fri, Mar 16, 2012 at 10:57:13AM -0500, Chris Adams wrote: > > Once upon a time, Matthew Garrett said: > > > No package should be automatically changing the sysrq policy. > > > > Why not? > > > > For example, I use a commercial backup program that makes extensive use > > of IPC and needs the msgmni and msgmnb limits raised beyond the default > > values. Why shouldn't they be able to include that change in their RPM? > > What happens if two packages want to set a sysctl to different values ? Well, that's already a possibility with lots of the ".d" type solutions, so I don't see why sysctl.d is any different. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, Mar 16, 2012 at 10:57:13AM -0500, Chris Adams wrote: > Once upon a time, Matthew Garrett said: > > No package should be automatically changing the sysrq policy. > > Why not? > > For example, I use a commercial backup program that makes extensive use > of IPC and needs the msgmni and msgmnb limits raised beyond the default > values. Why shouldn't they be able to include that change in their RPM? What happens if two packages want to set a sysctl to different values ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On Fri, 2012-03-16 at 14:31 -0400, Gerry Reno wrote: > On 03/15/2012 10:46 PM, Gerry Reno wrote: > > On 03/15/2012 10:30 PM, Adam Williamson wrote: > > > >> On Thu, 2012-03-15 at 22:22 -0400, Gerry Reno wrote: > >> > >> > >>> Yeah, installed the beta and I'm still having the exact same problem. > >>> > >>> Graphics is Geforce FX 5600 > >>> > >>> > >> Ah. Then that'll be https://bugzilla.redhat.com/show_bug.cgi?id=745202 . > >> > >> > > Looks like it. > > > > My screen issues are a little bit different but I think it's the same > > underlying problem: driver issues. > > > > > > > > I just saw comment 47 in the bug. > > I'm not sure I understand the part about workaround with blacklisting. > > At no time do I have a working Terminal after reboot. And what exactly > ends up being blacklisted? I thought only drivers got blacklisted. How > do you blacklist a card? Does someone have an example? That's more a discussion for how we as the Fedora (and upstream GNOME) devs can fix the problem than how you as a user can fix it. The 'blacklist' we're talking about is GNOME's blacklist of cards that have 3D-accelerated drivers that seem to satisfy all the Shell requirements, but are in fact known to be incapable of satisfactorily rendering Shell. It's located at /usr/share/gnome-session/hardware-compatibility (in F17, anyway, I think it may have been different in F16). It blacklists based on the Mesa renderer string; the level of granularity it's capable of depends on how each Mesa driver decides to write its renderer string. For the main drivers (Intel, Radeon, Nouveau) it's possible to achieve pretty much GPU-level granularity. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
On 03/16/2012 05:15 PM, John Ellson wrote: > On 03/16/2012 05:13 AM, Michael Scherer wrote: >> Le jeudi 15 mars 2012 à 12:49 -0400, John Ellson a écrit : >>> Can we just generate "karma" from a comment in bugzilla please? Having >>> to find some other weird place to indicate that a fix "works for me" is >>> a real pain. >> Have you tried fedora-easy-karma ? >> https://fedoraproject.org/wiki/Fedora_Easy_Karma >> > > This is supposed to be easy? >"Run fedora-cert, included with fedora-easy-karma as a > dependency, to set up a certificate with your FAS credentials. " > > I'm sure "karma" is useful to Release-Engineering. I just think the > scope is wrong for a bug reporter. > > Take, for example: > > https://admin.fedoraproject.org/updates/NetworkManager-0.9.3.995-0.6.git20120314.fc17 > > > The update contains fixes for three problems: 800690, 798102, 802540 > > I contributed to the first bug, 800690, and duly tested and reported > "works for me", but I had no involvement in the other two, so I'm not in > a position to judge their "karma". > > I think these release updates should automatically gain partial, per-bug > karma from "works for me" in the bug reports. > > "karma" for the update in total needs to come from people in a > "release-engineering" role, rather than people in a "bug > reporting/fixing/testing role". > > I agree that people using an "update testing" repository are reasonable > candidates for the "release-engineering" role, but "bug > reporting/fixing/testing" role doesn't require "update testing". The > bugs fixes might be tested directly from koji, or from some private > builds, or even from local patching. > > I am trying to be constructive here. We're all busy people. I just > think that "karma" is outside of a reasonable workflow for a bug reporter. > > John > I agree with you, but we didn't find better way yet. Let's ask Luke if it's even possible. https://fedorahosted.org/bodhi/ticket/677 Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
On Fri, 2012-03-16 at 12:15 -0400, John Ellson wrote: > On 03/16/2012 05:13 AM, Michael Scherer wrote: > > Le jeudi 15 mars 2012 à 12:49 -0400, John Ellson a écrit : > >> Can we just generate "karma" from a comment in bugzilla please? Having > >> to find some other weird place to indicate that a fix "works for me" is > >> a real pain. > > Have you tried fedora-easy-karma ? > > https://fedoraproject.org/wiki/Fedora_Easy_Karma > > > > This is supposed to be easy? > "Run fedora-cert, included with fedora-easy-karma as a > dependency, to set up a certificate with your FAS credentials. " BTW, yes, that is actually very easy. Did you try running it? It doesn't require you to do anything scary. Absolutely no anal probes. We have dozens of people regularly filing karma via f-e-k. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
On Fri, 2012-03-16 at 12:15 -0400, John Ellson wrote: > On 03/16/2012 05:13 AM, Michael Scherer wrote: > > Le jeudi 15 mars 2012 à 12:49 -0400, John Ellson a écrit : > >> Can we just generate "karma" from a comment in bugzilla please? Having > >> to find some other weird place to indicate that a fix "works for me" is > >> a real pain. > > Have you tried fedora-easy-karma ? > > https://fedoraproject.org/wiki/Fedora_Easy_Karma > > > > This is supposed to be easy? > "Run fedora-cert, included with fedora-easy-karma as a > dependency, to set up a certificate with your FAS credentials. " > > I'm sure "karma" is useful to Release-Engineering. I just think the > scope is wrong for a bug reporter. > > Take, for example: > > https://admin.fedoraproject.org/updates/NetworkManager-0.9.3.995-0.6.git20120314.fc17 > > The update contains fixes for three problems: 800690, 798102, 802540 > > I contributed to the first bug, 800690, and duly tested and reported > "works for me", but I had no involvement in the other two, so I'm not in > a position to judge their "karma". > > I think these release updates should automatically gain partial, per-bug > karma from "works for me" in the bug reports. > > "karma" for the update in total needs to come from people in a > "release-engineering" role, rather than people in a "bug > reporting/fixing/testing role". > > I agree that people using an "update testing" repository are reasonable > candidates for the "release-engineering" role, but "bug > reporting/fixing/testing" role doesn't require "update testing". The > bugs fixes might be tested directly from koji, or from some private > builds, or even from local patching. > > I am trying to be constructive here. We're all busy people. I just > think that "karma" is outside of a reasonable workflow for a bug reporter. The 'karma' relates to the update as a whole, not any specific bug. What we're principally concerned with in the 'updates testing' process is not 'does this update fix the bugs it claims to fix' but 'does this update cause any major functionality regressions'. It's useful to read https://fedoraproject.org/wiki/Proven_tester in this context. It is/was intended as instructions for proven testers but it's useful reading for anyone in filing karma. The current system is clearly limited in quite a lot of ways. The single, numeric karma system really isn't sophisticated enough. I've mentioned this several times, and wrote a fairly long post explaining the advantages of a more complex system (and hence, by implication, the drawbacks of the current system) at https://lists.fedoraproject.org/pipermail/test/2011-November/104579.html . Luke has had Bodhi 2.0 in the works for a while, now. A large part of what Bodhi 2.0 will do is what's described in that post - allow for multiple, possibly-dynamically-definable types of feedback on updates, rather than a single 'karma number' for each update. That might be an appropriate time to try and work some kind of connection between Bugzilla and Bodhi. But I still think it might be very difficult to do; it's very difficult to parse a freeform Bugzilla comment and be sure whether it means 'the update's good' or 'the update's bad', and implementing some kind of 'tick here if the update works' box in Bugzilla requires downstream patching of Bugzilla, which we're currently quite heavily opposed to. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17-alpha: UI unusable
On 03/15/2012 10:46 PM, Gerry Reno wrote: > On 03/15/2012 10:30 PM, Adam Williamson wrote: > >> On Thu, 2012-03-15 at 22:22 -0400, Gerry Reno wrote: >> >> >>> Yeah, installed the beta and I'm still having the exact same problem. >>> >>> Graphics is Geforce FX 5600 >>> >>> >> Ah. Then that'll be https://bugzilla.redhat.com/show_bug.cgi?id=745202 . >> >> > Looks like it. > > My screen issues are a little bit different but I think it's the same > underlying problem: driver issues. > > > I just saw comment 47 in the bug. I'm not sure I understand the part about workaround with blacklisting. At no time do I have a working Terminal after reboot. And what exactly ends up being blacklisted? I thought only drivers got blacklisted. How do you blacklist a card? Does someone have an example? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
Once upon a time, Matthew Garrett said: > On Fri, Mar 16, 2012 at 10:57:13AM -0500, Chris Adams wrote: > > Once upon a time, Matthew Garrett said: > > > No package should be automatically changing the sysrq policy. > > > > Why not? > > > > For example, I use a commercial backup program that makes extensive use > > of IPC and needs the msgmni and msgmnb limits raised beyond the default > > values. Why shouldn't they be able to include that change in their RPM? > > Where did I say they shouldn't? You mean other than the quoted line? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Dan Williams > On Wed, 2012-03-14 at 20:47 +0100, Lars Seipel wrote: >> The current behaviour of tearing down working IPv6 connections is >> just painful IMHO. > > If the IPv6 method is "ignore" (which is the current default) then NM > shouldn't be touching IPv6 stuff on that interface; kernel-assigned > routes and addresses should be there and untouched by NM. Is that not > the case? For WiFi, no. When timing out DHCPv4 and failing the connection, NM takes the entire interface, along with any working IPv6 connectivity, down with it. (Also, on WiFi, it appears the default IPv6 method has been Automatic for quite some time.) (Of course, this entire discussion is now moot.) -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/default in Fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2012 12:47 PM, Adam Williamson wrote: > On Fri, 2012-03-16 at 09:56 +0100, Matej Cepl wrote: >> On 15.3.2012 09:38, Tomasz Torcz wrote: Why and why just us? >>> >>> Good question, we deviate from upstream default: >>> http://wiki.apache.org/httpd/DistrosDefaultLayout >> >> Do we have somebody to make the stupid item 3 go away? >> >> # If you're having issues with authorization and your permissions >> are # correct make sure that you try testing with SELinux turned >> off. Run # 'setenforce 0' and use 'chcon' to fix permissions. Run >> 'ls -alZ' to # view the current permissions.' SELinux first >> appeared in Fedora Core # 3, RHEL 4, and CentOS 4. >> >> httpd in Fedora/RHEL/CentOS works with SELinux just fine. >> Anything else are bugs, which need to be filed. > > Well, it works just fine so long as you understand the various > httpd contexts and that you'll have to set the context on any file > that things running on your server genuinely need to be able to > write. So we should probably ask them to link to > http://linux.die.net/man/8/httpd_selinux or something similar. We just released much -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9jeXMACgkQrlYvE4MpobNnhgCcCCRuwUuuBAb3UWff1ue3BuL/ auAAn1gzFt88Wa7rins76Ay9Z+OP/618 =pK4U -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, Mar 16, 2012 at 10:57:13AM -0500, Chris Adams wrote: > Once upon a time, Matthew Garrett said: > > No package should be automatically changing the sysrq policy. > > Why not? > > For example, I use a commercial backup program that makes extensive use > of IPC and needs the msgmni and msgmnb limits raised beyond the default > values. Why shouldn't they be able to include that change in their RPM? Where did I say they shouldn't? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide compose failing?
El Fri, 16 Mar 2012 15:59:49 +0100 Stijn Hoop escribió: > On Fri, 16 Mar 2012 08:11:24 -0600 > Kevin Fenzi wrote: > > > On Fri, 16 Mar 2012 14:02:39 +0100 > > Stijn Hoop wrote: > > > > > Hi, > > > > > > did I miss the last two days of rawhide compose mails or are they > > > failing? If so where can I check? > > > > http://lists.fedoraproject.org/pipermail/devel/2012-February/162652.html > > > > It looks like they composed, but didn't send email for some reason. > > > > Will investigate. > > > > kevin > > Thanks. > > Actually I do see an error in critpath.log, > > http://kojipkgs.fedoraproject.org/mash/rawhide-20120316/logs/critpath.log > > Maybe that explains? I refactored the scripts that build rawhide this week to enable primary and secondary arches to use the same scripts. in that i broke the bit that sends email. im testing a fix for it now. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-XML-XPath] 680418 - missing man page for xpath applied debian patch, which added POD into xpath code, but also
commit 06198004f6132c58258cfdf3d930f05f1b784c4b
Author: Marcela Mašláňová
Date: Fri Mar 16 17:41:28 2012 +0100
680418 - missing man page for xpath
applied debian patch, which added POD into xpath code, but also fix debian
bug(#185292)
perl-XML-XPath.spec | 11 ++-
xpath.man.patch | 259 +++
2 files changed, 267 insertions(+), 3 deletions(-)
---
diff --git a/perl-XML-XPath.spec b/perl-XML-XPath.spec
index beaaea9..8b3714c 100644
--- a/perl-XML-XPath.spec
+++ b/perl-XML-XPath.spec
@@ -1,6 +1,6 @@
Name: perl-XML-XPath
Version:1.13
-Release:16%{?dist}
+Release:17%{?dist}
Summary:XPath parser and evaluator for Perl
@@ -9,6 +9,7 @@ License:GPL+ or Artistic
URL:http://search.cpan.org/dist/XML-XPath/
Source0:http://www.cpan.org/authors/id/M/MS/MSERGEANT/XML-XPath-1.13.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Patch0: xpath.man.patch
BuildArch: noarch
BuildRequires: perl(XML::Parser)
@@ -24,7 +25,7 @@ this as they support functionality beyond XPath.
%prep
%setup -q -n XML-XPath-%{version}
-
+%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -38,7 +39,6 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {}
';'
find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
-
%check
make test
@@ -52,10 +52,15 @@ rm -rf $RPM_BUILD_ROOT
%doc README TODO
%{_bindir}/xpath
%{perl_vendorlib}/XML
+%{_mandir}/man1/xpath*
%{_mandir}/man3/*.3*
%changelog
+* Fri Mar 16 2012 Marcela Mašláňová - 1.13-17
+- 680418 - missing man page for xpath
+- applied debian patch, which added POD into xpath code, but also fix debian
bug(#185292)
+
* Fri Jan 13 2012 Fedora Release Engineering
- 1.13-16
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/xpath.man.patch b/xpath.man.patch
new file mode 100644
index 000..349f7fd
--- /dev/null
+++ b/xpath.man.patch
@@ -0,0 +1,259 @@
+Author: Ardo van Rangelrooij
+Description:
+ * examples/xpath: patched by Fabien Ninoles
+(thanks Fabien!)
+ * examples/xpath: fixed erroneous handling of filenames containing a '-'
+(closes: Bug#185292)
+ * examples/xpath: fixed various small typos in the POD
+(closes: Bug#180508)
+
+diff -up XML-XPath-1.13/examples/xpath.old XML-XPath-1.13/examples/xpath
+--- XML-XPath-1.13/examples/xpath.old 2001-02-14 13:43:33.0 +0100
XML-XPath-1.13/examples/xpath 2012-03-16 17:31:58.812485837 +0100
+@@ -1,74 +1,113 @@
+ #!/usr/bin/perl -w
++
++eval 'exec /usr/bin/perl -w -S $0 ${1+"$@"}'
++if 0; # not running under some shell
+ use strict;
+
+ $| = 1;
+
+-unless (@ARGV >= 1) {
+- print STDERR qq(Usage:
+-$0 [filename] query
+-
+- If no filename is given, supply XML on STDIN.
+-);
+- exit;
+-}
+-
+ use XML::XPath;
+
+-my $xpath;
+-
++my @paths;
+ my $pipeline;
++my $SUFFIX = "\n";
++my $PREFIX = "";
++my $quiet = 0;
++
++PARSE: while ((@ARGV >= 1) && ($ARGV[0] =~ /^-./ )) {
++ OPTIONS: {
++ if ($ARGV[0] eq "-e") {
++ shift;
++ push @paths, shift;
++ last OPTIONS;
++ }
++ if ($ARGV[0] eq "-p") {
++ shift;
++ $PREFIX = shift;
++ last OPTIONS;
++ }
++ if ($ARGV[0] eq "-s") {
++ shift;
++ $SUFFIX = shift;
++ last OPTIONS;
++ }
++ if ($ARGV[0] eq "-q") {
++ $quiet = 1;
++ shift;
++ last OPTIONS;
++ }
++ print STDERR "Unknown option ignore: ", shift;
++ }
++}
++
++unless (@paths >= 1) {
++ print STDERR qq(Usage:
++$0 [options] -e query [-e query...] [filename...]
++
++ If no filenams are given, supply XML on STDIN.
++ You must provide at least one query. Each supplementary
++ query is done in order, the previous query giving the
++ context of the next one.
++
++ Options:
++
++ -q quiet. Only output the resulting PATH
++ -s suffix use suffix instead of linefeed.
++ -p postfix use prefix instead of nothing.
++);
+
+-if ($ARGV[0] eq '-p') {
+- # pipeline mode
+- $pipeline = 1;
+- shift @ARGV;
+-}
+-if (@ARGV >= 2) {
+- $xpath = XML::XPath->new(filename => shift(@ARGV));
+-}
+-else {
+- $xpath = XML::XPath->new(ioref => \*STDIN);
+-}
+-
+-my $nodes = $xpath->find(shift @ARGV);
+-
+-unless ($nodes->isa('XML::XPath::NodeSet')) {
+-NOTNODES:
+- print STDERR "Query didn't return a nodeset. Value: ";
+- print $nodes->value, "\n";
+ exit;
+ }
+
+-if ($pipeline) {
+- $nodes = find_more($nodes);
+-
Re: /etc/default in Fedora
On 03/16/2012 04:56, Matej Cepl wrote: On 15.3.2012 09:38, Tomasz Torcz wrote: Why and why just us? Good question, we deviate from upstream default: http://wiki.apache.org/httpd/DistrosDefaultLayout Do we have somebody to make the stupid item 3 go away? # If you're having issues with authorization and your permissions are # correct make sure that you try testing with SELinux turned off. Run # 'setenforce 0' and use 'chcon' to fix permissions. Run 'ls -alZ' to # view the current permissions.' SELinux first appeared in Fedora Core # 3, RHEL 4, and CentOS 4. httpd in Fedora/RHEL/CentOS works with SELinux just fine. Anything else are bugs, which need to be filed. Matěj Short of educating web server administrators about SELinux and the correct labels for web resources I'm not sure what else can be done. You don't want to use restorecond to make sure the directories are labeled properly because you could potentially use an improperly configured file upload capability to drop whatever pages you want onto the server and it would fixup the labels. Unfortunately education is the best option but not the easiest. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, Mar 16, 2012 at 2:47 PM, Lennart Poettering wrote: /etc/sysctl.conf is interpreted after /etc/sysctl.d is. The former hence overrides settings in the latter. and Muayyad AlSadi responded: > but this does not make sense > > the idea behind all .d is to allow packages to provide default (either > kernel defaults or distro defaults) > because the other choice is to use %post and sed The setup of conf/oneBigFile + conf.d/manySmallFiles is so common (see the list of them on my system, below) that maybe there should be a convention on which one overrides which. Most of the packages using this configuration method are configured by reading oneBigFile, which then explicitly loads conf.d/*. In other cases, both configuration methods seem to be compiled in, and it is not clear which one is done first and thus possibly overridden. The override order is determined by whether the changes are before or after the conf.d/* invocation. If the conf.d/* load is in the beginning of oneBigFile's contents, the settings from the conf.d/* files are overridden. This is how sysctl.conf behaves. It makes more sense to me that files in conf.d override the main file, e.g. because they are loaded at the end of the oneBigFile. I prefer this behavior because the individual files in conf.d/ directory can be provided by optional components, which, in this scheme, don't have to touch the main config file. /etc/httpd/conf.d /etc/php.d /etc/dracut.conf.d /etc/ld.so.conf.d /etc/prelink.conf.d /etc/reader.conf.d /etc/X11/xorg.conf.d /etc/dracut.conf.d/01-dist.conf /etc/fonts/conf.d /etc/polkit-1/localauthority.conf.d /etc/polkit-1/nullbackend.conf.d /etc/reader.conf.d /etc/revisor/conf.d /etc/revisor-unity/conf.d /etc/yum/pluginconf.d /usr/share/X11/xorg.conf.d /usr/share/alsa/alsa.conf.d /usr/share/ghostscript/conf.d -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 680418] missing man page for xpath
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=680418 Marcela Mašláňová changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE Last Closed||2012-03-16 12:38:12 --- Comment #2 from Marcela Mašláňová 2012-03-16 12:38:12 EDT --- I applied debian patch, which added the pod part into xpath file. Also patch fixes the erroneous handling of filenames containing a '-' was applied (debian: Bug#185292). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: This "karma" stuff is a pain!
On Fri, Mar 16, 2012 at 10:15 AM, John Ellson wrote: > https://admin.fedoraproject.org/updates/NetworkManager-0.9.3.995-0.6.git20120314.fc17 > > The update contains fixes for three problems: 800690, 798102, 802540 > > I contributed to the first bug, 800690, and duly tested and reported "works > for me", but I had no involvement in the other two, so I'm not in a position > to judge their "karma". Looking at this specific case, I think it would have been appropriate for dcbw to go ahead and add karma to this update, with a note that this is "proxy karma" and linking to your comment #10 on that bug. I regularly add karma to updates in Bodhi myself, but I've also seen devs add "proxy karma" for me in order to move things along. - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/default in Fedora
On Fri, 2012-03-16 at 09:56 +0100, Matej Cepl wrote: > On 15.3.2012 09:38, Tomasz Torcz wrote: > >> Why and why just us? > > > > Good question, we deviate from upstream default: > > http://wiki.apache.org/httpd/DistrosDefaultLayout > > Do we have somebody to make the stupid item 3 go away? > > # If you're having issues with authorization and your permissions are > # correct make sure that you try testing with SELinux turned off. Run > # 'setenforce 0' and use 'chcon' to fix permissions. Run 'ls -alZ' to > # view the current permissions.' SELinux first appeared in Fedora Core > # 3, RHEL 4, and CentOS 4. > > httpd in Fedora/RHEL/CentOS works with SELinux just fine. Anything else > are bugs, which need to be filed. Well, it works just fine so long as you understand the various httpd contexts and that you'll have to set the context on any file that things running on your server genuinely need to be able to write. So we should probably ask them to link to http://linux.die.net/man/8/httpd_selinux or something similar. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
On 03/16/2012 05:13 AM, Michael Scherer wrote: Le jeudi 15 mars 2012 à 12:49 -0400, John Ellson a écrit : Can we just generate "karma" from a comment in bugzilla please? Having to find some other weird place to indicate that a fix "works for me" is a real pain. Have you tried fedora-easy-karma ? https://fedoraproject.org/wiki/Fedora_Easy_Karma This is supposed to be easy? "Run fedora-cert, included with fedora-easy-karma as a dependency, to set up a certificate with your FAS credentials. " I'm sure "karma" is useful to Release-Engineering. I just think the scope is wrong for a bug reporter. Take, for example: https://admin.fedoraproject.org/updates/NetworkManager-0.9.3.995-0.6.git20120314.fc17 The update contains fixes for three problems: 800690, 798102, 802540 I contributed to the first bug, 800690, and duly tested and reported "works for me", but I had no involvement in the other two, so I'm not in a position to judge their "karma". I think these release updates should automatically gain partial, per-bug karma from "works for me" in the bug reports. "karma" for the update in total needs to come from people in a "release-engineering" role, rather than people in a "bug reporting/fixing/testing role". I agree that people using an "update testing" repository are reasonable candidates for the "release-engineering" role, but "bug reporting/fixing/testing" role doesn't require "update testing". The bugs fixes might be tested directly from koji, or from some private builds, or even from local patching. I am trying to be constructive here. We're all busy people. I just think that "karma" is outside of a reasonable workflow for a bug reporter. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
Once upon a time, Matthew Garrett said: > No package should be automatically changing the sysrq policy. Why not? For example, I use a commercial backup program that makes extensive use of IPC and needs the msgmni and msgmnb limits raised beyond the default values. Why shouldn't they be able to include that change in their RPM? If not, what's the point of /etc/sysctl.d? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, 2012-03-16 at 15:16 +, Matthew Garrett wrote: > On Fri, Mar 16, 2012 at 04:13:31PM +0200, Muayyad AlSadi wrote: > > > > > > As I understand it, Muayyad has different problem. Right now, the > > > /etc/sysctl.conf we ship is not empty. It has several values set, one of > > > them is sysrq=0 he used in his example. No one set this is value, it's > > > just > > > default value and yet, no package can change it by placing its file in > > > /etc/sysctl.d This would work only if sysctl.conf is empty and all default > > > configuration is moved to /etc/sysctl.d/00-systemdefault.conf > > > > yes exactly this is the case, > > we have sysrq=0 in /etc/sysctl.conf > > No package should be automatically changing the sysrq policy. No Fedora package should do that. However I can imagine situation when sysadmin wants his own package to do it. I have to second the request to be the default /etc/sysctl.conf empty and moving the Fedora defaults to sysctl.d/00-systemdefault.conf. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mass deduplication and reassignment of ABRT bugs
As a part of the ABRT Backtrace Deduplication Service[1], we are planning to close and reassign old ABRT bugs in bugzilla. Bugs which were found to have similar backtraces will be closed as duplicates of the bug with most CCed users. If the bugs originate from different components and their backtraces have a common part traced to another component, the bug may be also reassigned. We would like to run it sometimes next week, possibly on Tuesday. The bugzilla changes will be made from abrt-...@fedoraproject.org account and it will close about one third of the currently opened ABRT bugs with parsable backtrace. You can already see some of the expected results in the testing bugzilla at partner-bugzilla.redhat.com. If your bug was closed or reassigned incorrectly, please reopen or reassign it back, it will not be touched again by the bot. A full log of the currently planned bugzilla actions is here: http://mlichvar.fedorapeople.org/tmp/dedup.actions.bz2 Summary: ACTIONS: CLOSE_DUPLICATE: 2632 CHANGE_COMPONENT: 144 SUGGEST_DUPLICATE: 229 SUGGEST_COMPONENT: 75 COMPONENTS: TOP10 closed as dup: 315: rhythmbox 298: nautilus 171: gvfs 122: totem 93: gnome-online-accounts 93: gnome-shell 75: control-center 63: empathy 58: gnome-panel 50: notification-daemon TOP10 unassigned: 16: totem 14: gnome-shell 12: nautilus 9: rhythmbox 5: control-center 4: brasero 4: notification-daemon 4: transmission 3: gtkpod 2: tracker TOP10 assigned: 38: gtk2 17: gstreamer 14: gtk3 8: libX11 7: mesa 6: cairo 6: GConf2 5: gstreamer-plugins-base 4: python 4: qt BUGS: TOP10 deduped: 90: 737640 51: 658318 42: 739779 29: 755772 29: 717740 28: 712907 27: 703242 23: 660384 22: 751916 20: 753369 If you find a suspicious action, please let us know at crash-catc...@lists.fedorahosted.org or file a ticket at https://fedorahosted.org/abrt. [1] http://fedoraproject.org/wiki/Features/ABRTBacktraceDeduplication -- The ABRT Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, Mar 16, 2012 at 04:13:31PM +0200, Muayyad AlSadi wrote: > > > > As I understand it, Muayyad has different problem. Right now, the > > /etc/sysctl.conf we ship is not empty. It has several values set, one of > > them is sysrq=0 he used in his example. No one set this is value, it's just > > default value and yet, no package can change it by placing its file in > > /etc/sysctl.d This would work only if sysctl.conf is empty and all default > > configuration is moved to /etc/sysctl.d/00-systemdefault.conf > > yes exactly this is the case, > we have sysrq=0 in /etc/sysctl.conf No package should be automatically changing the sysrq policy. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about commiting the sources
2012/3/16 Bryn M. Reeves : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/16/2012 02:33 PM, Jan Synacek wrote: >> On 03/16/12 at 11:16am, Sergio Belkin wrote: >>> Perhaps and stupid question: >>> >>> After upload new-sources to repo, it outputs: Uploaded and added >>> to .gitignore: Source upload succeeded. Don't forget to commit >>> the sources file >>> >>> I don't understand! By default it add sources files to .gitignore >>> and then it asks for commit them? >>> >>> Is it something that I misunderstood? >>> >> >> It just tells you not to forget to commit the file named 'sources'. >> The file changes when you execute new-sources and should be >> commited, because it contains an md5sum of the source tarball. >> >> The message is somewhat misleading, because the 'sources' file gets >> staged automatically after new-sources, so if you do fedpkg commit, >> it gets commited anyway. > > It's also a bit unclear in that the thing that was added to .gitignore > is the tarball file name (you don't want to check it into the VCS - > that's what the lookaside is for). Maybe it would be more explicit to > output a line like: > > Uploaded and added "fooble-1.2.3-rc3-git1.tar.gz" to .gitignore: > > Should be a quick & simple patch. > > Regards, > Bryn. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9jUWsACgkQ6YSQoMYUY95kswCgvJTVh/o5YSeY/Bv6sfOSKLwC > 7BAAnA3N+i0zu9rL3BzY0D501OfTk5nL > =lrjK > -END PGP SIGNATURE- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel +1 -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide compose failing?
On Fri, 16 Mar 2012 08:11:24 -0600 Kevin Fenzi wrote: > On Fri, 16 Mar 2012 14:02:39 +0100 > Stijn Hoop wrote: > > > Hi, > > > > did I miss the last two days of rawhide compose mails or are they > > failing? If so where can I check? > > http://lists.fedoraproject.org/pipermail/devel/2012-February/162652.html > > It looks like they composed, but didn't send email for some reason. > > Will investigate. > > kevin Thanks. Actually I do see an error in critpath.log, http://kojipkgs.fedoraproject.org/mash/rawhide-20120316/logs/critpath.log Maybe that explains? Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about commiting the sources
2012/3/16 Jon Ciesla : > On Fri, Mar 16, 2012 at 9:33 AM, Jan Synacek wrote: >> On 03/16/12 at 11:16am, Sergio Belkin wrote: >>> Perhaps and stupid question: >>> >>> After upload new-sources to repo, it outputs: >>> Uploaded and added to .gitignore: >>> Source upload succeeded. Don't forget to commit the sources file >>> >>> I don't understand! By default it add sources files to .gitignore and >>> then it asks for commit them? >>> >>> Is it something that I misunderstood? >>> >> >> It just tells you not to forget to commit the file named 'sources'. The file >> changes when you execute new-sources and should be commited, because it >> contains an md5sum of the source tarball. >> >> The message is somewhat misleading, because the 'sources' file gets staged >> automatically after new-sources, so if you do fedpkg commit, it gets commited >> anyway. > > The upload puts the new sources in the lookaside cache, which is > outside of git, and updates the sources file, but doesn't commit it to > git, because the assumption is that your have other changes to make, > like updating the spec, new patches perhaps, etc. > > -J > >> Hope this explanation is not even more confusing:) >> >> Best regards, >> -- >> Jan Synacek >> BaseOS team Brno >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel > > > > -- > in your fear, seek only peace > in your fear, seek only love > > -d. bowie > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org Thanks everyone for the explanation! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about commiting the sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2012 02:33 PM, Jan Synacek wrote: > On 03/16/12 at 11:16am, Sergio Belkin wrote: >> Perhaps and stupid question: >> >> After upload new-sources to repo, it outputs: Uploaded and added >> to .gitignore: Source upload succeeded. Don't forget to commit >> the sources file >> >> I don't understand! By default it add sources files to .gitignore >> and then it asks for commit them? >> >> Is it something that I misunderstood? >> > > It just tells you not to forget to commit the file named 'sources'. > The file changes when you execute new-sources and should be > commited, because it contains an md5sum of the source tarball. > > The message is somewhat misleading, because the 'sources' file gets > staged automatically after new-sources, so if you do fedpkg commit, > it gets commited anyway. It's also a bit unclear in that the thing that was added to .gitignore is the tarball file name (you don't want to check it into the VCS - that's what the lookaside is for). Maybe it would be more explicit to output a line like: Uploaded and added "fooble-1.2.3-rc3-git1.tar.gz" to .gitignore: Should be a quick & simple patch. Regards, Bryn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9jUWsACgkQ6YSQoMYUY95kswCgvJTVh/o5YSeY/Bv6sfOSKLwC 7BAAnA3N+i0zu9rL3BzY0D501OfTk5nL =lrjK -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about commiting the sources
On Fri, Mar 16, 2012 at 9:33 AM, Jan Synacek wrote: > On 03/16/12 at 11:16am, Sergio Belkin wrote: >> Perhaps and stupid question: >> >> After upload new-sources to repo, it outputs: >> Uploaded and added to .gitignore: >> Source upload succeeded. Don't forget to commit the sources file >> >> I don't understand! By default it add sources files to .gitignore and >> then it asks for commit them? >> >> Is it something that I misunderstood? >> > > It just tells you not to forget to commit the file named 'sources'. The file > changes when you execute new-sources and should be commited, because it > contains an md5sum of the source tarball. > > The message is somewhat misleading, because the 'sources' file gets staged > automatically after new-sources, so if you do fedpkg commit, it gets commited > anyway. The upload puts the new sources in the lookaside cache, which is outside of git, and updates the sources file, but doesn't commit it to git, because the assumption is that your have other changes to make, like updating the spec, new patches perhaps, etc. -J > Hope this explanation is not even more confusing:) > > Best regards, > -- > Jan Synacek > BaseOS team Brno > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about commiting the sources
On 03/16/12 at 11:16am, Sergio Belkin wrote: > Perhaps and stupid question: > > After upload new-sources to repo, it outputs: > Uploaded and added to .gitignore: > Source upload succeeded. Don't forget to commit the sources file > > I don't understand! By default it add sources files to .gitignore and > then it asks for commit them? > > Is it something that I misunderstood? > It just tells you not to forget to commit the file named 'sources'. The file changes when you execute new-sources and should be commited, because it contains an md5sum of the source tarball. The message is somewhat misleading, because the 'sources' file gets staged automatically after new-sources, so if you do fedpkg commit, it gets commited anyway. Hope this explanation is not even more confusing:) Best regards, -- Jan Synacek BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
Am 16.03.2012 15:21, schrieb Michal Schmidt: > Dne 16.3.2012 14:40, Michal Hlavinka napsal: >> As I understand it, Muayyad has different problem. Right now, the >> /etc/sysctl.conf we ship is not empty. It has several values set, one of >> them is sysrq=0 he used in his example. No one set this is value, it's >> just default value and yet, no package can change it by placing its file >> in /etc/sysctl.d This would work only if sysctl.conf is empty and all >> default configuration is moved to /etc/sysctl.d/00-systemdefault.conf > > See a related bug: > https://bugzilla.redhat.com/show_bug.cgi?id=760254 yes, but the really bug is that "sysctl.conf" is not shipped empty it should be the global place where the admin can override ANY setting from any other file/package and so it is correct to apply systcl.conf as last item - as said only if it would be shipped empty _ example: some package enables "net.ipv4.ip_forward" if i say as admin "net.ipv4.ip_forward = 1" in sysctl.conf this has usually a very good reason and no other random config file has to override this or force me to deal with hopefully high enough numbers in needed "/etc/sysctl.d/XX.config" if "sysctl.conf" ould be empty as default we would have excatly this behavior, and yes i am speaking from the view of a sysadmin maintaining a lot of virtual servers where "/etc/sysctl.conf" is distributed from a admin machine to all other guest systems signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Question about commiting the sources
Perhaps and stupid question: After upload new-sources to repo, it outputs: Uploaded and added to .gitignore: Source upload succeeded. Don't forget to commit the sources file I don't understand! By default it add sources files to .gitignore and then it asks for commit them? Is it something that I misunderstood? Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
Dne 16.3.2012 14:40, Michal Hlavinka napsal: As I understand it, Muayyad has different problem. Right now, the /etc/sysctl.conf we ship is not empty. It has several values set, one of them is sysrq=0 he used in his example. No one set this is value, it's just default value and yet, no package can change it by placing its file in /etc/sysctl.d This would work only if sysctl.conf is empty and all default configuration is moved to /etc/sysctl.d/00-systemdefault.conf See a related bug: https://bugzilla.redhat.com/show_bug.cgi?id=760254 Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
> > As I understand it, Muayyad has different problem. Right now, the > /etc/sysctl.conf we ship is not empty. It has several values set, one of > them is sysrq=0 he used in his example. No one set this is value, it's just > default value and yet, no package can change it by placing its file in > /etc/sysctl.d This would work only if sysctl.conf is empty and all default > configuration is moved to /etc/sysctl.d/00-systemdefault.conf yes exactly this is the case, we have sysrq=0 in /etc/sysctl.conf >> If a package places a sysctl file in /etc/sysctl.d/ then you can >> override it with /etc/sysctl.conf, hence everything is as it should, no? >> This whole logic is designed so that the admin's configuration always >> takes precedence over vendor configuration. Which is the right thing to >> do. the admin can have higher number like 99-local.conf or move every thing in /etc/sysctl.conf to /etc/sysctl.d/00-defaults.conf and have a single line in /etc/sysctl.conf saying # you can override /etc/sysctl.d/*.conf here possible values and their defaults are found in /etc/sysctl.d/00-defaults.conf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide compose failing?
On Fri, 16 Mar 2012 14:02:39 +0100 Stijn Hoop wrote: > Hi, > > did I miss the last two days of rawhide compose mails or are they > failing? If so where can I check? http://lists.fedoraproject.org/pipermail/devel/2012-February/162652.html It looks like they composed, but didn't send email for some reason. Will investigate. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On 03/16/2012 02:28 PM, Lennart Poettering wrote: On Fri, 16.03.12 14:54, Muayyad AlSadi (als...@gmail.com) wrote: but this does not make sense the idea behind all .d is to allow packages to provide default (either kernel defaults or distro defaults) because the other choice is to use %post and sed eg. let's say I made a firewall package that needs to enable forwarding, it would put it in a sysctl.d If a package places a sysctl file in /etc/sysctl.d/ then you can override it with /etc/sysctl.conf, hence everything is as it should, no? This whole logic is designed so that the admin's configuration always takes precedence over vendor configuration. Which is the right thing to do. That said, note that it's probably a good idea if packages stick their sysctl files in /usr/lib/sysctl.d instead, so that that users can use /etc/sysctl.d/ to override that. /etc/sysctl.conf is read mostly for compatibility reasons only. As I understand it, Muayyad has different problem. Right now, the /etc/sysctl.conf we ship is not empty. It has several values set, one of them is sysrq=0 he used in his example. No one set this is value, it's just default value and yet, no package can change it by placing its file in /etc/sysctl.d This would work only if sysctl.conf is empty and all default configuration is moved to /etc/sysctl.d/00-systemdefault.conf Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, 16.03.12 14:54, Muayyad AlSadi (als...@gmail.com) wrote: > but this does not make sense > > the idea behind all .d is to allow packages to provide default (either > kernel defaults or distro defaults) > because the other choice is to use %post and sed > eg. let's say I made a firewall package that needs to enable > forwarding, it would put it in a sysctl.d If a package places a sysctl file in /etc/sysctl.d/ then you can override it with /etc/sysctl.conf, hence everything is as it should, no? This whole logic is designed so that the admin's configuration always takes precedence over vendor configuration. Which is the right thing to do. That said, note that it's probably a good idea if packages stick their sysctl files in /usr/lib/sysctl.d instead, so that that users can use /etc/sysctl.d/ to override that. /etc/sysctl.conf is read mostly for compatibility reasons only. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide compose failing?
Hi, did I miss the last two days of rawhide compose mails or are they failing? If so where can I check? Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
but this does not make sense the idea behind all .d is to allow packages to provide default (either kernel defaults or distro defaults) because the other choice is to use %post and sed eg. let's say I made a firewall package that needs to enable forwarding, it would put it in a sysctl.d what do you think ? what is the added value of having .conf overrides .d ? On Fri, Mar 16, 2012 at 2:47 PM, Lennart Poettering wrote: > On Fri, 16.03.12 14:40, Muayyad AlSadi (als...@gmail.com) wrote: > >> hi everybody, >> >> in recent fedora releases I can see we have /etc/sysctl.d/ >> >> but does it really get evaluated >> >> eg. let's put in /etc/sysctl.d/00-ojuba-enabled-sysrq.conf >> >> kernel.sysrq = 1 >> >> and keep it 0 in /etc/sysctl.conf >> >> kernel.sysrq = 0 >> >> then reboot then type >> >> sysctl kernel.sysrq >> >> it was reported that this would yield 0 (maybe when no wifi and no >> network at all) > > /etc/sysctl.conf is interpreted after /etc/sysctl.d is. The former hence > overrides settings in the latter. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > 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: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On Fri, 16.03.12 14:40, Muayyad AlSadi (als...@gmail.com) wrote: > hi everybody, > > in recent fedora releases I can see we have /etc/sysctl.d/ > > but does it really get evaluated > > eg. let's put in /etc/sysctl.d/00-ojuba-enabled-sysrq.conf > > kernel.sysrq = 1 > > and keep it 0 in /etc/sysctl.conf > > kernel.sysrq = 0 > > then reboot then type > > sysctl kernel.sysrq > > it was reported that this would yield 0 (maybe when no wifi and no > network at all) /etc/sysctl.conf is interpreted after /etc/sysctl.d is. The former hence overrides settings in the latter. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
hi everybody, in recent fedora releases I can see we have /etc/sysctl.d/ but does it really get evaluated eg. let's put in /etc/sysctl.d/00-ojuba-enabled-sysrq.conf kernel.sysrq = 1 and keep it 0 in /etc/sysctl.conf kernel.sysrq = 0 then reboot then type sysctl kernel.sysrq it was reported that this would yield 0 (maybe when no wifi and no network at all) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/default in Fedora
On 15.3.2012 09:38, Tomasz Torcz wrote: Why and why just us? Good question, we deviate from upstream default: http://wiki.apache.org/httpd/DistrosDefaultLayout Do we have somebody to make the stupid item 3 go away? # If you're having issues with authorization and your permissions are # correct make sure that you try testing with SELinux turned off. Run # 'setenforce 0' and use 'chcon' to fix permissions. Run 'ls -alZ' to # view the current permissions.' SELinux first appeared in Fedora Core # 3, RHEL 4, and CentOS 4. httpd in Fedora/RHEL/CentOS works with SELinux just fine. Anything else are bugs, which need to be filed. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Possible to access Koji build directory?
On Fri, 16 Mar 2012 12:01:59 +0100, Jim Meyering wrote: > However, I would suggest that any "make check"-spawned process that > does not terminate is a test script bug that should be fixed upstream, I agree. New testcases are reviewed with this rule in mind. But the existing testcases are handled by this killer app. > e.g., by prefixing the command with "timeout $n_seconds" for some > reasonable number of seconds. It does not work for existing testcases as they fork, setsid etc. various ways and 'timeout' will not catch them all. This is why gdb-orphanripper.c tracks them by pty and not by PID/PGRP/etc. (There are no privileged features available in buildroots.) Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
Le jeudi 15 mars 2012 à 12:49 -0400, John Ellson a écrit : > Can we just generate "karma" from a comment in bugzilla please? Having > to find some other weird place to indicate that a fix "works for me" is > a real pain. Have you tried fedora-easy-karma ? https://fedoraproject.org/wiki/Fedora_Easy_Karma -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Possible to access Koji build directory?
Jan Kratochvil wrote:
> On Fri, 16 Mar 2012 11:16:51 +0100, Jim Meyering wrote:
>> That works very well. However, the base64 output in my first log was
>> corrupt, due to some asynchronous output (stderr about job completion)
>> that was emitted in the middle of the big base64 block.
>> Adding the "sync; sleep 10" part below should avoid that in the future:
>
> FYI using automatic killer of leftover processes as some of them never
> finished
> and blocked builds, in other cases they kept running busy on build boxes etc.
>
> # Cleanup any leftover testsuite processes as it may stuck mock(1) builds.
> #
> http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-orphanripper.c;hb=master
> Source2: gdb-orphanripper.c
> gcc -o ./orphanripper %{SOURCE2} -Wall -lutil -ggdb2
> ./orphanripper make %{?_smp_mflags} -k $CHECK || :
Hi Jan,
Nice program. Thanks for sharing.
However, I would suggest that any "make check"-spawned process that
does not terminate is a test script bug that should be fixed upstream,
e.g., by prefixing the command with "timeout $n_seconds" for some
reasonable number of seconds.
Even though some systems lack timeout (introduced in coreutils-7.0 2008-10-05)
I still use it (e.g., in grep) along with an invocation of this function:
require_timeout_()
{
( timeout 10s true ) > /dev/null 2>&1 \
|| skip_ your system lacks the timeout program
timeout 10s false; test $? = 1 \
|| skip_ your system has a non-GNU timeout program
}
Then, the test is simply skipped on a system without "timeout".
Of course, if upstream cannot be bothered to correct the tests,
it's sure good to have your orphanripper program. Just don't
let it serve as an excuse to write sloppy tests.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
F-17 Branched report: 20120316 changes
Compose started at Fri Mar 16 08:15:27 UTC 2012 Broken deps for x86_64 -- [HippoDraw] HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.1-5.fc17.noarch requires ruby-nokogiri [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [amsn] amsn-0.98.4-9.fc17.x86_64 requires libgstfarsight-0.10.so.0()(64bit) [aunit] aunit-2010-3.fc16.i686 requires libgnat-4.6.so aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit) [catfish] catfish-engines-0.3.2-4.fc17.1.noarch requires pinot [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [couchdb] couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [empathy] empathy-3.3.5-3.fc17.x86_64 requires telepathy-butterfly empathy-3.3.5-3.fc17.x86_64 requires libtelepathy-farsight.so.0()(64bit) empathy-3.3.5-3.fc17.x86_64 requires libgstfarsight-0.10.so.0()(64bit) [eruby] eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) [gajim] gajim-0.15-0.4.beta4.fc17.noarch requires farsight2-python [ganyremote] ganyremote-5.13-2.fc17.noarch requires bluez-utils >= 0:3.35 [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gdal] gdal-ruby-1.7.3-12.fc17.x86_64 requires libruby.so.1.8()(64bit) [gearmand] gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) gearmand-0.23-2.fc17.x86_64 requires libmemcached.so.8()(64bit) gearmand-0.23-2.fc17.x86_64 requires libboost_program_options-mt.so.1.47.0()(64bit) [genius] genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) [ghc-conduit] ghc-conduit-0.2.2-1.fc17.i686 requires libHSlifted-base-0.1.0.3-ghc7.0.4.so ghc-conduit-0.2.2-1.fc17.i686 requires ghc(lifted-base-0.1.0.3) = 0:3cd2f5651657fddd87690f7280ea9d3b ghc-conduit-0.2.2-1.fc17.x86_64 requires libHSlifted-base-0.1.0.3-ghc7.0.4.so()(64bit) ghc-conduit-0.2.2-1.fc17.x86_64 requires ghc(lifted-base-0.1.0.3) = 0:f261afc8420a2629ebb4586fc5993f75 ghc-conduit-devel-0.2.2-1.fc17.i686 requires ghc-prof(lifted-base-0.1.0.3) = 0:3cd2f5651657fddd87690f7280ea9d3b ghc-conduit-devel-0.2.2-1.fc17.i686 requires ghc-devel(lifted-base-0.1.0.3) = 0:3cd2f5651657fddd87690f7280ea9d3b ghc-conduit-devel-0.2.2-1.fc17.x86_64 requires ghc-prof(lifted-base-0.1.0.3) = 0:f261afc8420a2629ebb4586fc5993f75 ghc-conduit-devel-0.2.2-1.fc17.x86_64 requires ghc-devel(lifted-base-0.1.0.3) = 0:f261afc8420a2629ebb4586fc5993f75 [gnatcoll] gnatcoll-2011-6.fc17.i686 requires libgnat-4.6.so gnatcoll-2011-6.fc17.i686 requires libgnarl-4.6.so gnatcoll-2011-6.fc17.x86_64 requires libgnat-4.6.so()(64bit) gnatcoll-2011-6.fc17.x86_64 requires libgnarl-4.6.so()(64bit) [gnome-phone-manager] gnome-phone-manager-0.66-9.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnome-user-share] gnome-user-share-3.0.1-3.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [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) [gphpedit] gphpedit-0.9.95-0.2.20090209snap.fc15.x86_64 requir
Re: Bug 803646- Password is visible on gnome-terminal
On 03/16/2012 11:21 AM, Anish Patil wrote: Hi, The description of the bug says " With English-typing-booster enabled on gnome-terminal, while using su- command, password appears in the text". English typing booster is IBUS-IME for english language. Any thoughts or comments regrading solution will be appreciated. I've left the note below on the BZ. Hope it helps, Niels english-typing-booster should probably check the flags of the tty. For example: 1) write something on the terminal $ echo hello world 2) disable echo'ing $ stty -echo 3) write something again $ echo hello world 4) enable echo'ing $ stty echo 5) write something again $ echo hello world My terminal shows (including input): [ndevos@ndevos-laptop ~]$ echo hello world hello world [ndevos@ndevos-laptop ~]$ stty -echo [ndevos@ndevos-laptop ~]$ hello world [ndevos@ndevos-laptop ~]$ [ndevos@ndevos-laptop ~]$ echo hello world hello world [ndevos@ndevos-laptop ~]$ I am not sure if gnome-terminal offers a way to check the flags in a terminal, but you will probably want to have this functionality for any terminal emulator. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 803646- Password is visible on gnome-terminal
Hi, 2012/3/16 Anish Patil : > > Hi, > > The description of the bug says " With English-typing-booster enabled on > gnome-terminal, while using su- command, password appears in the text". > English typing booster is IBUS-IME for english language. > > Any thoughts or comments regrading solution will be appreciated. April Fools' Day? :) > > Regards, > Anish Patil. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Possible to access Koji build directory?
On Fri, 16 Mar 2012 11:16:51 +0100, Jim Meyering wrote:
> That works very well. However, the base64 output in my first log was
> corrupt, due to some asynchronous output (stderr about job completion)
> that was emitted in the middle of the big base64 block.
> Adding the "sync; sleep 10" part below should avoid that in the future:
FYI using automatic killer of leftover processes as some of them never finished
and blocked builds, in other cases they kept running busy on build boxes etc.
# Cleanup any leftover testsuite processes as it may stuck mock(1) builds.
#
http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-orphanripper.c;hb=master
Source2: gdb-orphanripper.c
gcc -o ./orphanripper %{SOURCE2} -Wall -lutil -ggdb2
./orphanripper make %{?_smp_mflags} -k $CHECK || :
Regards,
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libdb-5.3.15 update with soname bump
On 03/16/2012 09:17 AM, Jindrich Novy wrote: Hi all, very soon I'm going to update libdb to 5.3.15 in rawhide. Perhaps now would be a good time to make a concerted effort to move all db4 users over to libdb to avoid problems like these: https://bugzilla.redhat.com/show_bug.cgi?id=768846 (httpd+mod_perl and BerkeleyDB incompatibility) https://bugzilla.redhat.com/show_bug.cgi?id=712943 (After upgrade from Fedora 14 to 15, sendmail segfaults) Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bug 803646- Password is visible on gnome-terminal
Hi, The description of the bug says " With English-typing-booster enabled on gnome-terminal, while using su- command, password appears in the text". English typing booster is IBUS-IME for english language. Any thoughts or comments regrading solution will be appreciated. Regards, Anish Patil. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Possible to access Koji build directory?
Jim Meyering wrote:
> Richard W.M. Jones wrote:
>> On Tue, Mar 13, 2012 at 10:00:59AM +0100, Jan Kratochvil wrote:
>>> On Tue, 13 Mar 2012 09:45:22 +0100, Richard W.M. Jones wrote:
>>> >
>>> > I suspect the answer is 'no', but is is possible to access or download
>>> > the build directory of a failed build, on the Fedora Koji servers?
>>>
>>> GDB (and GCC) tar and uuencode their testsuite results into build.log:
>>> * Mon Jun 21 2004 Andrew Cagney 1.200400607.4
>>> - Tar/uuencode both the .sum and .log test results.
>>>
>>> It is a bit hack, providing back also other files besides rpms would be
>>> great
>>> but in fact it works well enough this way.
>>>
>>> Using then a simple extraction script build.log -> files (*.{sum,log}):
>>>
>>> http://git.jankratochvil.net/?p=nethome.git;a=blob_plain;f=bin/gdbunpack;hb=master
>>
>> Neat trick, thanks :-)
>
> Thanks to both of you.
> That works very well. However, the base64 output in my first log was
> corrupt, due to some asynchronous output (stderr about job completion)
> that was emitted in the middle of the big base64 block.
> Adding the "sync; sleep 10" part below should avoid that in the future:
>
> Instead of the usual %check rule,
>
> make %{?_smp_mflags} check
>
> I now use this, when needed:
>
> # After a failed make check, tar up, compress and base64-encode all results
> # The "sync; sleep 10" should ensure that no async output is printed
> # in the middle of the big base64 block.
> make %{?_smp_mflags} check \
> || { st=$?; tar cf - . | xz -9 | base64; sync; sleep 10; exit $st; }
In retrospect, the sync should not be needed.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Possible to access Koji build directory?
Richard W.M. Jones wrote:
> On Tue, Mar 13, 2012 at 10:00:59AM +0100, Jan Kratochvil wrote:
>> On Tue, 13 Mar 2012 09:45:22 +0100, Richard W.M. Jones wrote:
>> >
>> > I suspect the answer is 'no', but is is possible to access or download
>> > the build directory of a failed build, on the Fedora Koji servers?
>>
>> GDB (and GCC) tar and uuencode their testsuite results into build.log:
>> * Mon Jun 21 2004 Andrew Cagney 1.200400607.4
>> - Tar/uuencode both the .sum and .log test results.
>>
>> It is a bit hack, providing back also other files besides rpms would be great
>> but in fact it works well enough this way.
>>
>> Using then a simple extraction script build.log -> files (*.{sum,log}):
>>
>> http://git.jankratochvil.net/?p=nethome.git;a=blob_plain;f=bin/gdbunpack;hb=master
>
> Neat trick, thanks :-)
Thanks to both of you.
That works very well. However, the base64 output in my first log was
corrupt, due to some asynchronous output (stderr about job completion)
that was emitted in the middle of the big base64 block.
Adding the "sync; sleep 10" part below should avoid that in the future:
Instead of the usual %check rule,
make %{?_smp_mflags} check
I now use this, when needed:
# After a failed make check, tar up, compress and base64-encode all results
# The "sync; sleep 10" should ensure that no async output is printed
# in the middle of the big base64 block.
make %{?_smp_mflags} check \
|| { st=$?; tar cf - . | xz -9 | base64; sync; sleep 10; exit $st; }
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
libdb-5.3.15 update with soname bump
Hi all, very soon I'm going to update libdb to 5.3.15 in rawhide. Thanks, Jindrich -- Jindrich Novyhttp://people.redhat.com/jnovy/ Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá, kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl. --- Jan Werich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: This "karma" stuff is a pain!
On 03/15/2012 08:24 PM, Kevin Kofler wrote: Adam Williamson wrote: Luke Macken does Bodhi. It certainly sounds non-trivial to me, for a start, Bodhi uses FAS and Bugzilla does not. It would be trivial if these decisions would be made by a human who is CCed on both (i.e. the maintainer of the package) rather than by software. Kevin Kofler Policy always hinders the most talented workers (in this case, the best package maintainers). The purpose of policy is to limit the damage a less experienced package maintainer can do. How do we prevent an inexperienced package maintainer from prematurely pushing updates to stable? Perhaps you could allow package maintainers to add karma, but only on a special page. The page has a short blurb explaining karma policy, and if the maintainer wants to add karma himself, they have to click the reason they're adding karma. ( ) "Works for me" Comment in bugzilla ( ) etc.. (other acceptable reasons) This is probably only worth the effort if there is more than one acceptable reason, and they are sufficiently common. Emanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
