Log from Fri March 25 2011. Time is in Australian EST (UTC+10)

09:01 < svu> whot, I am not convinced it is a good idea to use rt deps as bt deps
09:04 < whot> svu: why not?
09:06 < svu> whot, well, because it does not protect anybody.
09:06 < svu> builder will make sure that his system is ok
09:07 < svu> then he distributes tar.gz/rpm/deb - and (unless rpm/deb have explicit deps) the user can have troubles anyway
09:07 < svu> it is much better if rpms/deps are built with proper deps
09:07 < svu> that's sane
09:08 < svu> but that's not upstream business
09:08 < svu> whot, so, what exactly we are trying to achieve? who we want to protect?
09:08 < whot> right now, if I install xkeyboard-config from git on my machine i'll have broken layouts
09:09 < svu> ok, just for you personally I, I see:)
09:09 < whot> and there's nothing that'll tell me why. xk-c didn't complain and events are generated fine. just for some reason the layouts end up empty
09:09 < svu> well, xkbcomp will fail
09:10 < whot> not really, because I hardly ever use sinhala :)
09:10 < svu> well, so it is not even for you!
09:10 < whot> no. you'd be surprised at the number of bugs I'm trying to fix these days taht don't affect me at all
09:10 < svu> for those few who use sinhala, who build from upstream tarballs (only xk-c but not xproto!)
09:10 < whot> well, just imagine the same happening on us
09:11 < svu> well, if I use some upstream stuff (not from distro, bleeding edge) - i expect that anything can be broken
09:11 < svu> and sometimes it is my fault, not upstream fault
09:12 < svu> because I picked project A from git while using project B from distro (without explicit dependency between versions)
09:12 < whot> i agree that we don't _have_ to do it, but we might as well make life a bit easier. because this is something that every xk-c packager has to figure out. and unless you write it into the announce email it is nontrivial
09:12 < whot> note that the check can be disabled easily, it is really just an aid
09:12 < svu> ok. do I understand it right that your patch does not change default behavior?
09:13 < whot> it does. by default it will complain if the dependencies aren't there, but you can disable that error
09:13 < svu> or wait... by default you do check? I  would prefer the default to remain the same
09:13 < whot> because i've learned that adding options to help people is rather pointless when they're not affecting the default build :)
09:13 < svu> well, you cannot help people who do not read configure --help ;)
09:14 < whot> do you read configure --help for each package each time a new version comes out?
09:14 < whot> i don't. it's not the most exciting thing to do
09:14 < svu> sure not. but when something does not work - I read everything that might be relevant :)
09:15 < whot> mind you, in this case that is _after_ you've already lost your keyboard :)
09:15 < svu> no bother, USA layout is hard to lose :)
09:15 < alanc> I thought all the patch does if the dependencies are missing is print a warning and go on, not stop the build from running, so it shouldn't hurt too badly anyway
09:15 < svu> and then you will start reading
09:15 < whot> it prints a warning, the missing dependencies and how to get around this check
09:16 < whot> but it should wake up those where the build breaks
09:16 < whot> out of interest, would it build on your machine?
09:16 < svu> AC_MSG_ERROR
09:16 < svu> perhaps not
09:16 < svu> because I do not have that version of xproto
09:16 < svu> and I do not need sinhala:)
09:16 < whot> so if the layout "us" was affected, you'd have just lost your keyboard
09:17 < alanc> oh, I saw the AC_MSG_WARN around the main output string and missed the AC_MSG_ERROR after it
09:17 < svu> Ctl-Alt-F1
09:17 < whot> assuming that works :)
09:17  * svu nearly promises never break layout 'us'
09:17 < whot> can we stop treating "us" as a first-level language just because we use it?
09:17 < alanc> if your layout was broken, wouldn't that include the server control keys?
09:18 < svu> whot, well, if nothing helps - reboot to runlevel s :)
09:18 < whot> note that the default layout for the X server is configure-time specified, so you're not even guaranteed that "us" is the fallback default
09:18 < alanc> the X server has no magic keys anymore, fully reliant on XKB for all the magic
09:18 < svu> whot, well, IIRC 'us' is the default language that is used when nothing helps. Am I wrong?
09:19 < svu> anyway, if worst comes to worst, there is runlevel s, runlevel 3 at least
09:19  * whot remembers how much he hated having a us layout on a german keyboard when things went wrong
09:19  * svu loves 'us' layout - blind typining rules
09:19 < svu> typing
09:20 < whot> shift ö for colon was my favourite hatred
09:20 < jcristau> does the fall back even work these days?  iirc at some point when the xkb config was broken the x server just went on happily with an empty keymap?
09:20 < svu> oh my. that's cruel
09:21 < whot> jcristau: merged a patch couple of weeks ago to fall back to default if the layout didn't have symbols
09:21 < whot> that doesn't guarantee the default works of course
09:21 < jcristau> whot: yeah, but that helps for bad config
09:21 < jcristau> i wasn't sure if that was merged yet
09:21 < svu> well, my point is that this all can and should be sorted and tested by distroes
09:21 < svu> end-users should not bother
09:21 < whot> svu: so we're at point where we expect the user to powercycle and reboot into runlevel 3 because we didn't put out a configure warning about missing run-time dependencies?
09:22 < svu> except for the ones who live on the edge
09:22 < jcristau> distro builders don't all use sinhala
09:22 < jcristau> so they won't notice until a user gets a broken keymap and reports the problem
09:22 < svu> whot, what if distromaker had "dirty" environment with bleeding edge xproto? while shipping more concervative previous version?
09:23 < whot> svu: it's a balance between "not our problem" and "not our problem but it's easy to help everyone who will have the problem"
09:23 < whot> svu: well, then xk-c would complain about missing libX11.
09:23 < svu> why?
09:24 < whot> and the distromaker could choose "screw sinhala, I'm going for it! yeehaw!" with --disable-runtime-deps
09:24 < whot> (yeehaw not required for proceeding)
09:24 < whot> you currently need xproto and libX11 to get sinhala, so if you have bleeding edge xproto, you're still missing libX11
09:24 < svu> I am talking about different scenario. Distromaker is building xk-c with newest xproto installed on his machine. So - no build-time warning
09:25 < svu> but the user have "stable" xproto
09:25 < svu> and we have again  the problem of runlevel 1
09:25 < whot> correct, but in that case we can't do anything
09:25 < svu> exactly
09:26 < whot> mind you, in my case koji regularly fails because I didn't push something into fedora but had it installed locally.
09:27 < svu> :)
09:27 < svu> you see :)
09:27 < whot> so locally works fine, but submitting a koji build then complains that e.g. xproto in fedora isn't up to scratch and I need to build that first
09:27 < whot> which is kinda the point of the patch, right now I wouldn't get that warning
09:27 < whot> and once I see the warning, I can update the Requires as well and magic will sort the rest out
09:31 < svu>  in your case you won't see the warning, because on YOUR system things are new, right?:)
09:32 < jcristau> he sees it in the failed koji build log
09:32 < whot> the local build would succeed but it would fail when I push into fedora
09:32 < whot> so none of my users would get affected
09:33 < svu> I see, you want the "clean build env" to report you about those things
09:33 < svu> so that warning is for distros that have something koji-like
09:37 < svu> whot, ok, if you really insist on having that warning enabled by default (which I am not exited about) - I kindly ask to not to FAIL. To have it as a warning
09:38 < svu> it would be too intrusive
09:40 < whot> i still don't understand why, but I can change the patch
09:40 < svu> especally for people who do not use sinhala
09:40 < svu> well, because this requirement even for runtime is not mandatory
09:40 < whot> urgh. forget that we're talking about sinhala. yes, that's the trigger this time but it might be "us" or "ru" next time
09:41 < svu> will you see that warning in koji logs?
09:41 < svu> or you just do not look at the warnings?
09:41 < whot> yes, as in the warning will be there. no, as in I won't notice if the build succeeds
09:42 < svu> not vigilant:)
09:42 < whot> the day only has 24h and I have to spend some of those on other things
09:44 < svu> ok. let's do it your way. You're increasing my pain to make life easier for distros! I will have to use that option!
09:44 < whot> not just you, me too.
09:45 < whot> as I said, I don't always get to benefit directly from changes. dont zap was such a case too, now I have to enable it everywhere
09:45 < svu> yes, don't zap was probably hard on upstream
09:46  * svu has to learn how to sacrifice and adjust priorities
09:47 < whot> i guess we could make this warning optional on whether building from git but that gets a bit overcomplicated
09:47 < whot> how often do you run configure anyway?
09:48 < whot> (from scratch that is)
09:50 < whot> svu: mind if I copy this discussion into the bug. this way you can at least blame me if someone complains to you :)
09:51 < svu> no problem
09:52 < whot> thx (and thx for commmitting too)