[00:13] desrt: they're like the NSA, they track you [00:13] ya... i get the general gist of the thing... but i have no idea why it has to be so complicated [00:14] with different cgroups for all different things plus this pseudofs to track it all... [00:38] hallyn: you mean enabled == 0 right? the paste you gave me shows num_cgroups == 1 for all of them [00:42] yeah [02:05] desrt: ack [02:13] stgraber: http://paste.ubuntu.com/7778221/ if a package installs real init and upstart scripts, upstart will DTRT and ignore the sysv scripts, rigth? (seems to be working here) I usually see sysvinit *wrapper*s cripts and had expected the package to only install the upstart scripts... [02:13] but I guess qemu-system-x86 also has a real sysv script, so must be ok [02:13] anyway i'm thinking of pushing that to utopic so if you see any problems with that pls shout [02:14] hallyn: one more big btw: g_error() terminates the calling process :) [02:15] it's quite strange to see free() calls after this :) === ikonia is now known as Guest70019 === kgunn is now known as Guest2511 === hyperair is now known as Guest84654 === neunon is now known as Guest28427 [02:26] hallyn: yes, it'll do the right thing [02:32] cool, thx, will probabablyh push to utopic tonight then [02:33] desrt: wtf? g_critical terminating the process makes sense. g_error? it's just an error... so waht's the recommended way to just log something? [02:43] all tests still pass both on host and in container. pushing === _salem is now known as salem_ [02:44] hallyn: g_warning [02:45] hallyn: btw... UserUnit has slice_path (char*), which it passes to cgmanager_create_all, which is expecting a ScopeUnit* [02:45] desrt: i could be mixing the terms up in my head, but i swear when i looked at a gnome page this morning it said g_critical and g_warning could both end the program [02:46] that's obviously not right... but it's also not clear what is the correct thing to do here [02:46] hallyn: they can, but typically don't [02:46] hm, that sounds like something i fixed this morning [02:46] you can set G_DEBUG=fatal-criticals or fatal-warnings [02:46] (the ScopeUnit pasing) [02:46] * hallyn checks [02:47] but in general: g_error > g_critical > g_warning > g_message > d_debug [02:47] g_error = fatal, always [02:47] g_critical = you made a programmer error and it's somewhat likely that your internal state was compromised [02:47] g_warning = something bad happened, but it may not have been the programmer's fault [02:47] desrt: oh, the .h file doesnt' match the .c, that's all :) [02:47] g_message = fyi [02:47] i had updated cgmanager.c and scope-unit.c [02:47] hallyn: awesome... [02:48] i wont' fix it now since i assume you ahve a buttload of other fixes [02:48] scope-unit has the wrong code, though.... [02:48] and wouldnt' want to merge those [02:48] why? [02:48] cgmanager_create_all(pu); [02:48] sorry... user-unit [02:48] my eyes are starting to cross from the scope/service/slice terms :) [02:48] oh. feh. [02:49] most importantly: what pids would i pass here? [02:49] none? [02:49] in cgmanager_create_all? [02:49] yes [02:49] this API looks a bit different now... [02:49] the pids which we pulled out of the StartTransientUnit msg, i.e. what logind sent us [02:50] came as a a(sv) where v was a ai [02:50] uh, au [02:50] each u is a pid to be moved; but again there's only ever 1 afaict [02:50] okay [02:50] so the properties handling should be done for both types of units, then [02:51] right now you're only doing it for the one... [02:51] regarding naming - blah i completely agree, i was trying ot make sense of the names being used by systemd, but still don't fully understand [02:51] i guess a scope limits all of a user's sessions; [02:51] a session describes a sesssion, and there' sa slice for each session; a service is i think something that doesn't make sense for non-systemd to do [02:51] right, i'm doing it for the one pid [02:52] so, the user-unit proably should just do something different, or nothing at all [02:53] it depends on whether a scope will soemtimes come with a slice; if so, then we'll need another function in cgmanager.c to create the cgroups for it (and pass it the UserUnit) [02:54] fwiw, here's how things are shaping up: http://ur1.ca/hq27o [02:54] i'm not exactly sure how you want the error handling to look here.... [02:54] like, if we fail to move one pid, do we fail the entire operation? [02:54] do we try to do back-out? [02:54] or do we just assume that the rest will be OK and continue? [02:55] i think we log and continue [02:55] then at least user has a chance to see that something went wrong [02:55] k. that's what i'm doing. [02:55] it also speeds things up: we can issue all the async calls pipelined [02:55] no need to wait for the replies [02:56] cool [02:57] where are you intending to open the connection to cgmanager? around each create_all/remove_all? [02:57] no. only once ever. [02:57] (actually we should probably just drop remove_all) [02:57] i store it in a static [02:57] if cgmanger restarts, will the connection auto-reestablish? [02:57] see the (buggy) 'initialised' code [02:57] no. [02:58] that can probably be fixed [02:58] but it raises an interesting question: what if we try to connect to it for the first time while it is mid-restart? [02:58] oh, i see now, i glossed over the _call before [02:58] should we keep trying each time we get a new request and spam on g_warning() each time? [02:59] the idea that this thing could restart under us is slightly horrifying.... [02:59] * desrt <- hates races, no matter how theoretical [02:59] true. if it were going to stick aroudn longer term we might consider re-exec upstart-style [03:00] but i do hope cgmanger becomes a relic soon. meaning systemd starts to offer what we need. [03:00] well the good news is that systemd-shim auto-exits... [03:00] oh, to answer, yeah; i thin krestart and spam warnings [03:00] nothing wrong with spam warnings, if bad things are in fact happening [03:00] auto-exits? [03:00] ya [03:00] after a period of inactivity [03:01] it's stateless [03:01] so why hang around? [03:01] oh, good. and how the heck does it get started! [03:01] dbus activation [03:01] i think you mean, magic [03:01] :) [03:01] dbus activation is really very nice.... arguably the best part about dbus, in fact [03:01] you just send a message to the service... [03:01] if it's there... great [03:01] if not -- it will be :) [03:02] and it's all race-free [03:02] ahhh, memories of inetd <3 [03:02] ya. more or less... [03:02] you say race-free, [03:02] well, actually [03:02] there's one teensy tiny race [03:02] but i'm the only one who ever noticed it..... [03:02] and nobody else seems to care [03:02] i say 'threading with nih-dbus seems to break' [03:03] but it is fixed with kdbus, at least [03:03] libdus-1 is a single-thread library as far as i'm concerned... [03:03] there are some nominal attempts at thread safety inside of it, but they didn't make it far enough .... and no real testing [03:04] yeah, i read some of the history on it :( [03:04] gdbus on the other hand is a multithread monster [03:04] this is some seriously awesome example of how to handle threading properly [03:04] ....and the trouble that you can get naive programmers into when you do so [03:04] turns out because of it's "threads are awesome" approach, there are some things that 'just work' in dbus-1 that are much harder in gdbus :( [03:05] classic example is registering object paths after successfully acquiring a bus name [03:06] in dbus-1 world this is perfectly logical, and there is no race: you don't return to the mainloop to process the incoming message queue until after the object is already registered from the same thread [03:06] in gdbus you have trouble: another thread is already processing the incoming messages before you have a chance to register your objects [03:06] sometimes stupid is better...... [03:07] complexity is complex [03:07] * hallyn wonders how long until we're talkign about capabilities, esp since sarnold is around [03:08] linux style "capabilities" are evil :( [03:08] itym POSIX :) [03:09] nope [03:09] fortunately, there was never agreement about this stuff at POSIX [03:09] itym posix-draft :) [03:09] (not for lack of trying....) [03:09] eh [03:09] well, as maintainer of capabilitiesin the kernel, when something appropriate comes along i'll ack the patch removing posix caps :) [03:09] we'll see when that happens [03:09] give me seccomp or give me death :) [03:10] peopel are always trying. but the alternative is always worse [03:10] * hallyn points to lxc WE GOT SECCOMP :) [03:10] * desrt <3 capsicum [03:10] ah, but it attaches capabilities to fds :) [03:10] but yes i'm attracted to capsicum [03:10] i wonder if you've seen memfd ;) [03:10] hallyn: man who did you upset to get stuck with maintaining caps in the kernel? :) [03:11] sarnold: amorgan [03:11] we have these new things called "seals" that you can apply to fds now, via fcntl [03:11] introduce a few more seals, mix in some seccomp, and we more or less have capsicum :) [03:12] yeah there are presentations coming on capsicum in linux, i'm hopeful [03:12] that would be such a win [03:12] well, we'll see whether people end up able to use them properly. but again i'm hopeful === Ursinha is now known as Ursinha-afk [03:16] slangasek: ok so i just pushed a new cgmanager (_0.26-0ubuntu6) to utopic which has the sysvinit scripts so should be usable for debian. There is an existing ITP with an old version by dba with very different packaging. Is there a protocol for, i dunno, replacing/updating the ITP with the utopic version or something close to it, for jessie? [03:19] hallyn: the protocol is that you ask me to upload it; ITPs are advisory locks only [03:20] hallyn: so did that file look OK to you? [03:21] fwiw, i'm having trouble telling the difference between scope unit and user unit if they both take the same transient parameters [03:21] seems that they only used a different scheme for cooking up the path.... [03:22] /user/%d.user/c%d.session vs. /user/%d.user [03:22] which raises another question: can we create the session one without having first created the user one? === Ursinha-afk is now known as Ursinha [03:24] slangasek: oh - in that case i'll do a bunch more testing and get back to you thx :) [03:25] desrt: so yes, we *can* (and do bc of the bug you found in the user_scope) create teh session one without the user one, [03:25] what happens if we come along and create the other one later? [03:25] desrt: and since we currently don't do actual cgroup configuration, it'll be no different for now; [03:25] retroactive containment? [03:26] nothing; it' sjust an mkdir in the cgroupfs returning EEXIST [03:26] but i think it's possible for the /usr/%d.user one to have some basic containment, [03:26] which all sessions shoudl be subject to. [03:26] so at some point we'll want to have both properly handled; [03:27] but i've mainly looked at the session code so i'm guessing; lemme look at the logind code for the user scopes [03:27] that is, the /user/%d.user cgroups [03:29] ok, i dont' see any code in systemd doing anything like it though [03:32] desrt: so if you wanted to just remove the user-unit.c altogether (for now) it might be just as well [03:32] well [03:32] if systemd/logind every does slice configuration of /usr/%d.user then we can add it [03:32] i think that maybe we should have a new type of cgroup unit or something [03:32] since these two different types are really very similar [03:33] the only annoying bit is the way the Slice property is handled... [03:33] really i'm in no way attached to how i structured any of it - it fell out from how i discovered what the logidn protocol was doing [03:34] what's wrong with how the Slice property is handled? === salem_ is now known as _salem [03:44] slangasek: all right if we're going for itp then perhaps a new upstream cgmanager release is in order [03:45] as you wish :) [03:56] * desrt tries sleep for a bit [03:57] hopefully i will be better equipped to figure out some better way of dealing with *.scope and *.slice without special cases in the morning :) [04:17] Good morning [04:17] bdmurray: yes, I'll have a look [04:20] bdmurray: MP> cool, thanks! [04:29] stgraber: hm, that lxc autopkgtest regression looks "real" (deluser: The user `usernic-user' does not exist.), but the same version succeeded before [04:29] stgraber: could that be due to the new cgmanager? [04:30] (that's at least what britney is holding back) [04:30] ah, cgmanager itself is failing, too [04:32] cgmanager tests are passing for me locally; where is it failing? also 'deluser usernic-user' should only happen at end of tests, after we've purposely created it... [04:32] hallyn: you shold have gotten a mail about it, didn't you? [04:32] https://jenkins.qa.ubuntu.com/job/utopic-adt-cgmanager/25/ARCH=i386,label=adt/console [04:33] test 14 failed [04:33] it's not very verbose why it fails unfortunately [04:34] pitti: do those tests not get run in ppas? [04:35] hallyn: we have one or two manual autopkgtest jobs for PPAs (firefox), but not in general, no [04:36] pitti: can you re-fire the tests somehow? [04:36] hallyn: yes, I can, if that was a transient failure [04:37] hallyn: running [04:37] i'm hoping - bc liek i say i can't reproduce locally. i coudl also just push the 0.27-0ubuntu1 version (which is basically identical and i was going to push anyway)... [04:37] i'm testing both on vm and in container in same vm... [04:37] I also restarted LXC, just to confirm [04:38] i did at one point notice a weird error msg (an hour or two ago) about apport failing to upgrade, bad sysvinit script; [04:40] pitti: i'm still afraid i may have done something bad with the sysvinit scripts for cgmanager... would you mind taking a quick look at debian/*init and debian/rules (which i did not chnage) in the failed cgmanager version? [04:40] oh, here: [04:40] update-rc.d: warning: default stop runlevel arguments (0 1 6) do not match apport Default-Stop values (none) [04:41] err, apport? curious [04:41] oh, is that complaining about the upstart.vs.sysvinit stop values? [04:42] it's stop on runlevel [!2345] in upstart, no stop values in sysv [04:43] hallyn: no, that's usually a complaint that your init.d LSB header has different stop levels than the update-rc.d call in postinst [04:43] oh [04:43] hallyn: which init.d script is that? [04:43] /etc/init.d/apport ? [04:44] hallyn: ah, I thought we are still talking about cgmanager (as you wanted me to have a look there) [04:44] heh, sorry. yeah it's just coincidence [04:45] well i suppose it caught my eye bc it came up while i was tryign out the cgmanager sysvinit script patch [04:45] hallyn: right, thanks; I'll fix that [04:45] cool [04:46] (it's just a warning though) [04:46] hallyn: cgmanager failed again [04:48] hm. and lxc? [04:48] still running [04:48] FAIL: lxc-tests: /usr/bin/lxc-test-unpriv [04:48] --- [04:48] /usr/sbin/deluser: The user `lxcunpriv' does not exist. [04:48] hallyn: but it's already past that, so will fail again [04:49] so, same error [04:49] that doesn't sound like cgmanager, but it also doesn't look like a flaky test [04:49] what is the testbed here? [04:49] but there's a lot of stuff in -proposed [04:49] runs in a container? [04:49] hallyn: QEMU [04:50] (http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test) [04:51] * pitti runs cgmanager locally [04:52] * hallyn sets up an environment [04:54] bah - 'booting vm to run cloud-init' :) [04:54] hallyn: well, yes -- anything wrong with that? [04:54] these VMs use the cloud images, so they might as well use its setup machinery [04:55] pitti: only that they're not using lxc for the basic setup :) i'm on a rather slow temp laptop [04:55] hallyn: oh, you can of course also run them in LXC [04:56] yeah but i don't want any delta from what's ahppening in archive [04:56] so i'll take the hit [04:56] hallyn: so it succeeded locally here [04:56] with proposed enabled? [04:56] the test 14 doesn't say what it failed on, so hard to say [04:56] yes [04:57] hm. [04:57] adt-run --apt-pocket=proposed -U cgmanager --- qemu /home/martin-scratch/adt-utopic-amd64-cloud.img [04:57] well i coudl push a version with more verbosity in test 14 [04:57] could the base test image be bad on the tester? [04:57] so this could be dependent on system load, or time zone, or whatever [04:57] system load is plausible [04:58] hallyn: it's working fairly well for other tests, and it failed the same way 4 times now (on different machines) [04:58] but do those machines use shared (ceph) storage to store the canonical image? [04:59] no, it's just a normal local ext4 [04:59] well scratch that idea then [04:59] hallyn: do you have VPN set up? [04:59] no [05:00] halp - the OS a chance to collect more entropy! (Need 187 more bytes) [05:01] hm, we install haveged into the VMs, where do you see this? [05:01] running adt-run on my laptop [05:01] finally got past it [05:01] oh, for adt-run key creation [05:02] I should fix that to only run if you want to run local binaries [05:12] hm, fails on [05:12] Errors were encountered while processing: rsync [05:29] hallyn: sorry, missed your reply; rsync where? on package install? [05:32] right, during setup i guess [05:32] i was doing adt-run --apt-pocket=proposed -U cgmanager --- qemu ~/adt-utopic-amd64-cloud.img [05:32] pitti: so it never got to actual cgmanager test running [05:32] i. e. the rsync package failed to install? (do you have a log?) [05:33] that worked here [05:34] hallyn: so if you tell me how to squeeze more info out of test14, I'm happy to run it on the CI machine [05:34] (set -x or something?) [05:34] pitti: no, sorry i killed the term [05:34] pitti: oh i was just going to add some echos to show which 'exit 1' was happening [05:35] or that; set -x is quite nice for tests which don't use shunit or something else with verbose failures [05:35] i've got a hunch that it's exiting bc Remove xxx is succeeding when xxx/b exists, and it shouldn't [05:35] except if that happens there it hsould happen for us [05:35] pitti: there's not some weird environment where the test run with -e right? (exiting on command failure?) [05:36] hallyn: your test script determines that [05:36] pitti: ok my test script doesnt' set it [05:36] hallyn: i. e. if it's doing set -e or #!/bin/sh -e [05:36] TBH I consider set -e pretty much a must for every shell script [05:37] hallyn: but anyway, if your debian/tests/foo doesn't use it, it won't be implied from anywhere; there's on magic /bin/sh in the testbed [05:37] hallyn: so if your autopkgtest has allow-stderr, it's probably simplest to just add set -x [05:37] pitti: yeah if you can run with -x that'd be great [05:38] allow-stderr? dunno stgraber hooked that up, [05:38] * hallyn checks [05:38] yeah it's set [05:39] hallyn: oh, debian/tests/exercise does have set -eu [05:39] so it's well behaved [05:39] hallyn: so runtests.sh is indeed run under dash and -e [05:39] as debian/tests/exercise sources it, not execute [05:40] pitti: oh. well then i don't see how it ever passed. bc it does things like [05:40] cmd \n if [ $? -eq 0 ]; then fail; fi [05:41] hallyn: hm, I don't think we are looking at the same script [05:41] grep eq tests/runtests.sh -> no hit [05:41] oh, that's running test/*.sh [05:41] dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.Remove string:'memory' string:"xxx" int32:0 > /dev/null 2>&1 [05:41] if [ $? -eq 0 ]; then exit 1 [05:41] hallyn: right, ok; so runtests.sh runs with set -e, but it execs tests/test*.sh which don't [05:42] oh, ok [05:42] phew. not that running with -e woudl bother me, but i just wouldn't have understood hwo it ever passed before [05:42] so if you could just run with -x maybe we can figure it out [05:42] though i'm about to head to bed [05:43] hallyn: yes, doing now [05:43] hallyn: I can mail you the output [05:44] hallyn: I'll reply to the jenkins failure mail [05:46] pitti: thanks! [05:55] hallyn: sent [05:58] pitti: just reproduced it on jessie container. looks like it's a real bug [05:59] but i don't undestand it. well, hopefully tomorrow - gnight [06:00] oh ffs. no. NO! ti stopped reproducing. this is ridiculous === doko_ is now known as doko [06:25] hallyn: could perhaps be because the DC is running trusty's qemu? [06:49] Hi, who is willing to sponsor my patch for https://bugs.launchpad.net/gnome-desktop/+bug/1340544? [06:49] Ubuntu bug 1340544 in gnome-desktop3 (Ubuntu) "gnome-rr: The minimum brightness can not be 0." [Undecided,New] [07:09] seb128, Laney: do you know http://www.infinality.net/blog/infinality-freetype-patches/ ? [07:10] doko, no, why? [07:10] doko, but slangasek is the freetype maintainer [07:10] heh [07:39] pitti: Hi, thanks for applying my patch for LP 1299975? Can you also sponsor the upload to trusty? [07:39] Launchpad bug 1299975 in pm-utils (Ubuntu Trusty) "wireless script checks wrong sys file" [Undecided,Fix committed] https://launchpad.net/bugs/1299975 [07:41] pitti: sorry, found it in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text= [07:41] pitti: Thanks!!! [07:43] xnox, hey, should a Architecture: all package have Multi-Arch: foreign? like suru-icon-theme? [07:59] Whoopie: yw; mvo sponsored it to trusty yesterday [08:38] Saviq: yes, see e.g. ttf-ubuntu-font-family [08:39] Saviq: there is an open dpkg feature request to treat transitive arch:all packages as m-a:foreign but there are concerns if that's actually always correct to do. [08:39] xnox, mhm, got it [08:46] xnox, can you please have a look at https://code.launchpad.net/~saviq/ubuntu-themes/fix-multiarch/+merge/226418 [08:48] Saviq: i wonder if I should try silo release that straight away. [08:48] xnox, you mean bypassing silos? be my guest [08:49] Saviq: nah, as in me assigning the silo and doing it. [08:49] xnox, yeah lets [08:49] ' [08:49] xnox, lemme add a line [08:50] ugh if only gdocs wouldn't log me out all the time [08:50] Saviq, wait [08:50] oupf [08:51] * Saviq waiting [08:51] Saviq, if you do a themes landing, we might want to include some bugfixes ... can you give me some minutes to check that? [08:51] seb128, sure [08:51] Saviq, or do you prefer to do separate landings? [08:51] seb128, is fine [08:51] seb128, lemme know [08:51] seb128: i'd prefer separate. It's a packaging change only, which unblocks cross-building. [08:51] seb128: no theme changes at all, thus not blocked on testing that =) [08:52] should be a quick one, too [08:52] you guys decide :) [08:52] xnox, it's not like theme bugfixes need lot of testing [08:52] xnox, that's gtk themes, so desktop only [08:53] seb128: hm, there are a bunch approved. It's not desktop only, there are suru icons as well. [08:53] xnox, we don't need to list them all [08:54] ~mhr3/ubuntu-themes/fix-suru-inheritance looks simple [08:54] and we should land it, yeah [08:54] that would be nice to get yes [08:55] ~sil2100/ubuntu-themes/osk_design_icon_association_change [08:55] looks sensible as well (needs osk testing) [08:55] https://code.launchpad.net/~larsu/ubuntu-themes/three-twelve/+merge/225982 [08:55] would be nice to get as well [08:56] ~larsu/ubuntu-themes/three-twelve [08:56] yeap. [08:56] * xnox goes to adjust the landing line [08:56] thanks [08:57] how about https://code.launchpad.net/~tiheum/ubuntu-themes/suru-icons/+merge/226325 ? [08:58] well, it's waiting for Jouni's ACK, so let's maybe let it wait... [08:58] seb128: Saviq: huh, i don't have powers to change spreadsheet.... but have acls to assign silos. [08:58] We're pretty low on silos right now [08:58] xnox, are you logged in? google logs me out all the time recently [08:59] Saviq: I can't review ~tiheum branch above. I'd wait on it. [08:59] yeah [08:59] cjwatson: did notice, only one was free. probably best to wait for a few to clear out. [09:00] Saviq, xnox: I added the inherit and the gtk 3.12 ones ... anything else? [09:01] seb128, looks fine to me [09:01] xnox: granted [09:01] * didrocks shares ownership at the same time [09:02] sil2100: you owne the spreadsheet now, congrats! [09:02] (we can only have one owner) [09:03] seb128: tweaked tests and description [09:03] didrocks: uh oh, I do?! [09:03] didrocks: thank you ;p? [09:03] didrocks: only one owner -> webscale bus factor =) [09:03] sil2100: yw [09:03] xnox: isn't it? ;) [09:04] didrocks: i'm lovin it! [09:04] I guess the domain owner can reclaim ownership though [09:04] well, at least, I hope :) [09:04] xnox, thanks [09:04] other you fork it and create a "new new spreadsheet" [09:04] sil2100: btw, reminder that I guess you can rename the spreadsheet now to remove the new :) [09:05] didrocks: yeah, i'd think so too. I think on my googleapps as an admin i can revoke an app permission and thus transfer ownership of everything elsewhere. [09:05] I think nobody is using the old dead one [09:05] didrocks: and then reactivate app for that user. [09:05] yeah, would make sense [09:05] my awesomebar still remembers the old one [09:05] and I reinforce that by always picking it first :( [09:05] * didrocks looks if we can delete the old one [09:05] one sec [09:06] been trying to go to wiki/citrain lately [09:07] Laney: nuked [09:07] nice [09:55] * xnox thinks there is something wrong with libtool [09:55] current=3, age=1, revision=0 yet soname 2.1.0 [09:56] current-age == 2 [09:56] xnox: don't try to think about these numbers too hard; it'll melt your brain [09:57] pitti: yes, yes, i remember that now. [09:57] pitti: so upstream broke abi but didn't bump the numbers. [09:57] I think the resulting version number is (current-age).age.revision or so [09:57] * xnox runs git log -p on configure.ac to verify [09:58] xnox: ordinarily that's done in Makefile.am [09:58] xnox: grep for -version-info [09:58] (and yay for not using GNU option syntax, but meh) [09:58] pitti: well, in their case, they use variables in -version-info which are set in configure.ac as constants. [09:58] xnox: ah ok, osrry [09:58] pitti: last abi bump was by slangasek .... who is not upstream, so yeah upstream have no clue. [10:11] seems weird -> i should bump current by one and reset age to 0 [10:11] but that makes it jump from 2.1.0 to 4.0.0 [10:11] I had a nice page which explained all that the other day, but apparently I lost the bookmark [10:12] well, last time steve bumped both current and age by +1 [10:12]