Skip to contentSkip to conversation

configure: silence pkg-config's check for curses

PATCH Applied Vadim Evard 2 participants 4 messages Jan 18, 2013 – Jan 21, 2013

lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 configure: silence pkg-config's check for curses

---
 configure |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
configure +1 -1
index 4ebb60d..6211db9 100755
@@ -2039,7 +2039,7 @@ fi
 if test "$mingw32" = "yes" ; then
     curses_list="-lpdcurses"
 else
-    curses_list="-lncurses:-lcurses:$($pkg_config --libs ncurses)"
+    curses_list="-lncurses:-lcurses:$($pkg_config --libs ncurses 2>/dev/null)"
 fi
 
 if test "$curses" != "no" ; then

-- 1.7.10.4

#2 lore raw

Thank you!

By the way (sorry if this was discussed before and is a strong decision) I'd say e-mail based workflow is of course very flexible - and very very novice-unfriendly. Dash, I had to learn git commands I'd never use in my usual workflow with local or Github repos. And, well, I was not very good with that. 10 ways with 10 options in each. You all saw my previous patch mail with "fubar" header and no signed-off-by string.

Is there a reason you (team) don't use e.g. Github at least for trivial patches?

Regards,
Vadim

#3 lore raw
Quoted 10 lines · Vadim Evard

By the way (sorry if this was discussed before and is a strong decision) I'd say e-mail based workflow is of course very flexible - and very very novice-unfriendly. Dash, I had to learn git commands I'd never use in my usual workflow with local or Github repos. And, well, I was not very good with that. 10 ways with 10 options in each. You all saw my previous patch mail with "fubar" header and no signed-off-by string.

Is there a reason you (team) don't use e.g. Github at least for trivial patches?

Yes, the email-based approach is the most flexible but also has a learning curve. For one-time contributors it can seem like wasted effort.

The QEMU community is familiar with the email-based workflow and has customized it. One key idea is that all patches go through [email protected] - even trivial patches are exposed to code review from the whole community. A new vector for code submission still needs to keep this property.

For another open source project that I'm involved in I have set up a cronjob that sends GitHub pull requests to the project mailing list. This way the mailing list still sees all patches before they get committed. Replying to patches doesn't work though - you still need to log into GitHub in order to send comments to the author. I can't ask all QEMU developers to do that.

Any ideas how to make GitHub work with QEMU?

Stefan