| ojeq | @find ubuntu 13 | 03:21 |
|---|---|---|
| meetingology | ojeq: Error: "find" is not a valid command. | 03:21 |
| pitti | Good morning | 05:48 |
| didrocks | morning | 07:20 |
| larsu | morning! | 07:49 |
| didrocks | hey larsu! | 07:51 |
| larsu | hi didrocks! ça va? | 07:51 |
| didrocks | ça va bien, et toi ? | 07:52 |
| larsu | bien aussi, merci | 07:53 |
| * larsu dives into css again today | 07:53 | |
| didrocks | good luck! | 07:54 |
| * didrocks dives into why machine-id isn't recreated on boot by systemd | 07:55 | |
| larsu | it can't even do simple things like this? We're doomed. systemd will be the end of linux. And choice! | 07:58 |
| didrocks | ahah :) | 07:59 |
| didrocks | larsu: seriously, I wonder why it fails, / is mounted rw, the perms on /etc is fine… | 07:59 |
| didrocks | and if you run a simple wrapper later on, it will create the file without any issue | 08:00 |
| * didrocks takes the open() parameters one after another to see why fd < 0 | 08:00 | |
| larsu | weird. well, poettering is this ---> way | 08:01 |
| larsu | (at least in my irc client :P) | 08:01 |
| didrocks | larsu: I want to debug a little bit more beforehand | 08:02 |
| didrocks | larsu: but if you can get him comment on pitti and I's thread on the upstream ML, that would be appreciated :) | 08:02 |
| pitti | bonjour didrocks et larsu ! | 08:02 |
| larsu | hi pitti! | 08:02 |
| didrocks | bonjour pitti! | 08:03 |
| larsu | didrocks: I can't do more than you, ping him :) | 08:03 |
| larsu | didrocks: he usually comes online later, though | 08:03 |
| didrocks | larsu: where is the German connection? :) | 08:03 |
| pitti | simple deal -- send one beer, get one answer :) | 08:03 |
| pitti | didrocks: ah, having fun sprinkling lots of debug statements into this code and rebooting your VM? | 08:04 |
| pitti | one of the few cases where there's *such* a good excuse for printf() debugging :) | 08:05 |
| didrocks | pitti: indeed, started yesterday night, so I know why it doesn't create it in the code, and the tmpfs behavior is expected | 08:05 |
| larsu | printf debugging is the best, I don't know why people complain about it all the time | 08:05 |
| didrocks | pitti: however, the all case is that open("/etc/machine-id", O_RDWR|O_CREAT|O_CLOEXEC|O_NOCTTY, 0444); return a negative fd | 08:06 |
| didrocks | cause* | 08:06 |
| pitti | didrocks: what's errno? | 08:06 |
| didrocks | pitti: EROFS | 08:06 |
| didrocks | I opened /proc/mounts just before, / is rw | 08:06 |
| pitti | oh, heh | 08:06 |
| didrocks | /etc is populated with the right perms | 08:07 |
| didrocks | and if you use the wrapper script later on, all is fine, the file is created as expected | 08:07 |
| pitti | didrocks: but indeed that makes little sense -- it can apparently update the file if it exists as a 0-byte file | 08:07 |
| didrocks | (after the boot proceeded) | 08:07 |
| pitti | (hence our current workaround of truncating instead of rm) | 08:07 |
| didrocks | pitti: right, there is a fallback | 08:07 |
| didrocks | then, it tests if the file exists | 08:07 |
| didrocks | if the file exists and is empty, -> mount tmpfs | 08:07 |
| didrocks | and generate + write into it | 08:08 |
| pitti | didrocks: tmpfs to where? | 08:08 |
| didrocks | /etc/machine-id | 08:08 |
| didrocks | (thanks to the flag writable = false; in the code) | 08:08 |
| pitti | didrocks: oh, heh; but that's still wrong for our purpose indeed, as we actually want a permanent ID | 08:09 |
| didrocks | pitti: I guess it's working actually, because, it's also writing it as the dbus-id | 08:10 |
| didrocks | and then, for generating, it's picking up the dbus-id if it's coherent :) | 08:10 |
| didrocks | so your workaround kind of works | 08:10 |
| didrocks | but kind of ugly as well :p | 08:10 |
| didrocks | pitti: in case you didn't notice, but most of the machine-id that are generated I guess is thanks to systemd postinst script which is using the wrapper (calling exactly the same code) to stamp /etc/machine-id the first time | 08:11 |
| didrocks | still, I don't see why I'm getting this errno at boot, while all seems fine on the FS… | 08:12 |
| pitti | didrocks: yes, I know that one; but that won't get re-applied after image build and cleaning /etc | 08:12 |
| didrocks | right | 08:12 |
| pitti | didrocks: it's not apparmor that early during boot yet, right? (and we don't confine init anyway) | 08:13 |
| pitti | didrocks: so does the remount rw happen before? maybe that just takes a bit of time? | 08:13 |
| didrocks | I didn't look at that, I didn't see anything in dmesg when getting the errorno | 08:13 |
| pitti | didrocks: did you try with putting an all-healing sleep(1) before the open()? | 08:13 |
| didrocks | pitti: /proc/mounts should reflect the current state, right? | 08:13 |
| pitti | didrocks: yeah, it should | 08:13 |
| didrocks | ah, I did use printf, not went to the sleep-hack yet | 08:13 |
| didrocks | will try that | 08:14 |
| pitti | race condition debugger's best friend :) | 08:14 |
| didrocks | heh ;) | 08:14 |
| * pitti bows to your new systemd hacker | 08:14 | |
| didrocks | ahah, the "printfer + sleeper" hacker :p | 08:14 |
| jjohansen | didrocks, pitti: yep we aren't applying apparmor policy that early or to init | 08:14 |
| didrocks | yeah, dmesg was too quiet to blame apparmor :) | 08:15 |
| didrocks | thanks for confirming | 08:15 |
| pitti | yeah, that wouldn't make sense either | 08:15 |
| pitti | for now my best suspicion is some kind of race between making r/w and open, although I would have assumed the remount to be synchronous | 08:15 |
| didrocks | pitti: http://paste.ubuntu.com/9076436/ | 08:15 |
| didrocks | see the second part, "without machine-id" | 08:16 |
| didrocks | (I stripped some parts) | 08:16 |
| pitti | [ 2.739054] systemd[1]: Started Remount Root and Kernel File Systems. | 08:17 |
| pitti | didrocks: curious that this comes after the machine-id bits | 08:17 |
| didrocks | yeah, I wondered about that one | 08:17 |
| pitti | systemd[1]: rootfs / rootfs rw | 08:17 |
| didrocks | but look at /proc/mounts reports before | 08:17 |
| didrocks | yeah | 08:17 |
| pitti | but that comes before (but only 0.06 s) | 08:17 |
| didrocks | this is just before the open() | 08:17 |
| pitti | didrocks: oh wait, check line 47 | 08:17 |
| didrocks | argh | 08:18 |
| didrocks | ok, making sense | 08:18 |
| didrocks | clearly didn't spot that one yesterday night | 08:18 |
| didrocks | (when I added this debug) | 08:18 |
| pitti | didrocks: keep that pastebin, makes an excellent artifact for reporting the bug | 08:18 |
| didrocks | so, there is another mount on / on top of the current one, which is ro? | 08:18 |
| pitti | didrocks: maybe / is still the initramfs rootfs, I'm not sure | 08:19 |
| didrocks | oh, that early… | 08:19 |
| pitti | although that would be weird, AFAIK it's the initramfs itself which does the pivot_root | 08:19 |
| didrocks | right | 08:19 |
| pitti | systemd doesn't run in initramfs | 08:19 |
| didrocks | and systemd isn't in the initramfs yet | 08:19 |
| didrocks | (I heard there is some plan) | 08:19 |
| seb128 | oh, that channel is busy this morning | 08:19 |
| pitti | bonjour seb128 | 08:20 |
| pitti | seb128: yeah, welcome to #ubuntu-init-system-hackers :) | 08:20 |
| didrocks | pitti: ok, I think bug report time then? or should I try to look where this mounted / is coming from? | 08:20 |
| pitti | didrocks: so the remounting is systemd-remount-fs.service, and thus happens out of process | 08:21 |
| seb128 | pitti, wie gehts? | 08:21 |
| didrocks | ExecStart=/lib/systemd/systemd-remount-fs | 08:21 |
| pitti | didrocks: yeah, I guess so, then you can discuss how the code should get reordered to generate machine-id on a r/w root | 08:21 |
| didrocks | ah, indeed | 08:21 |
| didrocks | yeah | 08:21 |
| pitti | seb128: gut, danke! und Dir? | 08:21 |
| didrocks | pitti: let me add a sleep, just to confirm it's racy | 08:21 |
| pitti | didrocks: according to our current theory, no amount of sleep should help | 08:22 |
| didrocks | pitti: you don't think this target was started before? | 08:22 |
| pitti | didrocks: if it does help, we are back to "async remounting r/w" | 08:22 |
| seb128 | pitti, auch gut, danke | 08:22 |
| pitti | didrocks: nah, it first initializes, then starts units | 08:23 |
| pitti | didrocks: but actually, the "Booting up is supported only when" indicates that it might not even be considered a bug | 08:23 |
| didrocks | you're right, of course, [ 2.326811] systemd[1]: Found ordering cycle on local-fs.target/start | 08:23 |
| didrocks | the target is afterwards | 08:23 |
| pitti | didrocks: i. e. you run into case 3), while our workaround is case 2) | 08:24 |
| didrocks | pitti: yeah, I wonder however how this work with the empty /etc then | 08:24 |
| pitti | didrocks: can't hurt to ask on the ML | 08:24 |
| seb128 | pitti, didrocks, do you guys need systemd tester yet? or is that enough on the "known issue list" that you don't need more feedback yet? | 08:24 |
| pitti | seb128: both actually | 08:25 |
| didrocks | pitti: starting a second thread today you mean? :) | 08:25 |
| pitti | seb128: we have a good deal of stuff to work on, but that by far doesn't mean that we know about every boot race or breakage with customizations | 08:25 |
| seb128 | pitti, let me rephrase | 08:25 |
| pitti | didrocks: the other was yesterday :) | 08:25 |
| didrocks | yeah, I didn't phrase it correctly :) | 08:26 |
| didrocks | ok, let's do it | 08:26 |
| seb128 | if I opt in, am I going to run into 10 known gotcha and waste half a day dealing with known issues? | 08:26 |
| seb128 | e.g that wouldn't be useful work neither for me nor for you | 08:26 |
| pitti | seb128: ah -- no, it really should boot and work normally | 08:26 |
| didrocks | seb128: I guess you won't get blocked (hopefully) on anything | 08:26 |
| seb128 | or is that supposed to be "everything works, if you have an issue it's interesting and we should debug it together" | 08:26 |
| pitti | seb128: unless you use things like root on NFS or server-ish packages which only have an upstart job | 08:27 |
| didrocks | seb128: you can even try one boot without turning the switch on definitively | 08:27 |
| pitti | seb128: if your desktop doesn't boot, or hardware doesn't work etc, please do tell me | 08:27 |
| seb128 | k | 08:27 |
| pitti | seb128: as that's absolutely expected to work | 08:27 |
| seb128 | do I need to install special packages or just systemd? | 08:27 |
| pitti | seb128: don't install anything; for the first try, just boot with init=/bin/systemd | 08:27 |
| willcooke | g'morn | 08:27 |
| didrocks | hey willcooke | 08:28 |
| pitti | seb128: if you want to do that more permanently, you can install systemd-sysv, but it works just fine on the kernel cmd line | 08:28 |
| pitti | hey willcooke | 08:28 |
| seb128 | hey wik | 08:28 |
| seb128 | hey willcooke | 08:28 |
| larsu | morning willcooke | 08:29 |
| pitti | seb128: so go ahead, do it, and be amazed of the Lennart mugshot on the framebuffer during boot! | 08:33 |
| seb128 | lol | 08:34 |
| pitti | didrocks: ah, he thinks I was joking! | 08:34 |
| larsu | cute | 08:34 |
| seb128 | thanks, as much I would like to throw darts in my laptop's screen, I sort of need the screen :p | 08:34 |
| pitti | oh, and no pets within 50 m! | 08:35 |
| didrocks | pitti: "he"? | 08:35 |
| seb128 | happyaron, | 08:35 |
| seb128 | Dépaquetage de libfcitx-qt5-0:i386 (0.1.2-2ubuntu2) ... | 08:35 |
| seb128 | dpkg: erreur de traitement de l'archive /var/cache/apt/archives/libfcitx-qt5-0_0.1.2-2ubuntu2_i386.deb (--unpack) : | 08:35 |
| seb128 | tentative de remplacement de « /usr/lib/i386-linux-gnu/libfcitx-qt5.so.0.1 », qui appartient aussi au paquet fcitx-libs-qt5:i386 0.1.2-2build1 | 08:35 |
| seb128 | happyaron, known issue? | 08:35 |
| pitti | didrocks: read the two lines above | 08:36 |
| didrocks | ahah :) | 08:36 |
| happyaron | nope, I "though" it was handled, but could be wrong | 08:36 |
| seb128 | happyaron, just happened with today's vivid updates | 08:37 |
| seb128 | brb, restarting | 08:37 |
| * didrocks grrrr at thunderbird freezing again | 08:40 | |
| happyaron | haven't received that update (by not using main archive server | 08:41 |
| didrocks | pitti: sent, let's see how it goes, I hope my explanations are clear enough, feel free to annotate | 08:45 |
| pitti | didrocks: ack, thanks | 08:45 |
| didrocks | yw | 08:45 |
| pitti | didrocks: sounds clear enough to me, thanks! | 08:46 |
| didrocks | great ;) | 08:46 |
| === alf is now known as alf_ | ||
| seb128 | didrocks, pitti, if I've a process "/bin/systemd splash" running it's that systemd is in use? | 08:55 |
| seb128 | well in use as pid1 | 08:55 |
| pitti | seb128: yes; you can call "systemctl" to see if it works, too | 08:55 |
| seb128 | pitti, initctl works, but I guess that does magic to redirect to systemd jobs? | 08:56 |
| didrocks | seb128: then, can you try systemctl status as well and report the "State:" line? | 08:56 |
| seb128 | State: degraded | 08:56 |
| pitti | seb128: no, it doesn't; if "sudo initctl" works, then you have upstart running | 08:56 |
| pitti | seb128: but I believe you are looking at the session upstart | 08:56 |
| seb128 | pitti, indeed | 08:56 |
| seb128 | k, systemd is in use then | 08:57 |
| pitti | seb128: systemctl --failed ? | 08:57 |
| didrocks | ok, systemctl should have red (failed) lines, what are they? | 08:57 |
| seb128 | why is "Degraded"§? | 08:57 |
| pitti | seb128: (without the ?) | 08:57 |
| seb128 | ● ifup@eth1.service loaded failed failed ifup for eth1 | 08:57 |
| seb128 | ● ifup@virbr0.service loaded failed failed ifup for virbr0 | 08:57 |
| seb128 | ● ifup@wlan0.service loaded failed failed ifup for wlan0 | 08:57 |
| didrocks | ahah :) | 08:57 |
| didrocks | pitti: see, I'm not alone! :) | 08:57 |
| pitti | sudo systemctl show ifup@eth1.service | 08:57 |
| seb128 | is that fixed with the update from this morning? | 08:57 |
| pitti | didrocks: oh, you figure it's that same bug? | 08:57 |
| didrocks | I'm pretty sure | 08:58 |
| didrocks | seb128: no /run/network directory? | 08:58 |
| pitti | seb128: most likely, yes | 08:58 |
| seb128 | pitti, http://paste.ubuntu.com/9091049/ | 08:58 |
| pitti | seb128: do you have ls -l /etc/rc*.d/*networking* | 08:58 |
| seb128 | didrocks, no such dir | 08:58 |
| pitti | seb128: sorry, my bad -- I mean sudo systemctl status ifup@eth1.service | 08:58 |
| pitti | seb128: ok, same bug then -- I figure you don't have any sysvinit links to networking | 08:58 |
| seb128 | pitti, http://paste.ubuntu.com/9091050/ | 08:59 |
| pitti | thus /etc/init.d/networking doesn't get started | 08:59 |
| seb128 | lrwxrwxrwx 1 root root 20 août 11 10:19 /etc/rc0.d/K07networking -> ../init.d/networking | 08:59 |
| pitti | right, as I expected | 08:59 |
| didrocks | seb128: [ Didier Roche ] | 08:59 |
| didrocks | * debian/ifup@.service: add a ConditionPath on /run/network, to avoid | 08:59 |
| didrocks | failing the unit if /etc/init.d/networking is disabled. (Closes: #769528) | 08:59 |
| pitti | seb128: so, that failure is fixed with -6ubuntu1 | 08:59 |
| didrocks | yw ;) | 08:59 |
| seb128 | didrocks, <seb128> is that fixed with the update from this morning? | 08:59 |
| pitti | seb128: the more interesting question is: what disabled networking in the first place? | 08:59 |
| seb128 | yeah, I read the changelog on -changes | 08:59 |
| didrocks | so yeah ;) | 08:59 |
| seb128 | pitti, not me | 08:59 |
| pitti | seb128: you don't care much, as you use NM | 09:00 |
| pitti | but on a server that would be wrong | 09:00 |
| seb128 | right | 09:00 |
| didrocks | pitti: yeah, same for me, I didn't remember to have done that | 09:00 |
| pitti | I suspect that this is some kind of upgrade failure | 09:00 |
| didrocks | yeah | 09:00 |
| pitti | maybe ifupdown or initscripts do something funky | 09:00 |
| didrocks | or it's a deskop-team cabale :) | 09:00 |
| pitti | lrwxrwxrwx 1 root root 20 Okt 5 17:59 /etc/rc0.d/K06networking -> ../init.d/networking | 09:00 |
| pitti | lrwxrwxrwx 1 root root 20 Okt 5 17:59 /etc/rc6.d/K06networking -> ../init.d/networking | 09:00 |
| pitti | lrwxrwxrwx 1 root root 20 Nov 17 11:00 /etc/rcS.d/S09networking -> ../init.d/networking | 09:00 |
| pitti | I have this | 09:00 |
| pitti | i. e. rcS.d. | 09:01 |
| seb128 | I don't have the rcS.d one | 09:01 |
| pitti | seb128: ok, so that's interesting, thanks for pointing out; I was writing off didrocks' as local breakage | 09:01 |
| pitti | seb128: anyway, it's entirely harmless for now | 09:01 |
| seb128 | k | 09:01 |
| pitti | seb128: (the "degraded") | 09:01 |
| seb128 | well, I'm going to wait for the update to be available and reboot | 09:01 |
| pitti | seb128: desktop, networking, bluetooth etc. all as it should be? | 09:02 |
| seb128 | pitti, yeah, I didn't notice a visible difference so far | 09:02 |
| seb128 | oh, no | 09:02 |
| seb128 | no bluetooth! | 09:02 |
| seb128 | no indicator and the settings list no adapter found | 09:03 |
| seb128 | wth? | 09:03 |
| pitti | seb128: you probably disabled it in sysetm-settings | 09:03 |
| seb128 | disabled what? the indicator? | 09:03 |
| pitti | seb128: upstart scripts have a bug to never actually remember the status across reboots, although they try | 09:03 |
| didrocks | seb128: bluetooth entirely | 09:03 |
| pitti | seb128: yeah, indicator bug -- it doesn't appear if you have BT soft-killed | 09:03 |
| seb128 | no, unity-control-center sees no hardware | 09:03 |
| didrocks | if you enable it in g-c-c, you should get the indicator | 09:03 |
| didrocks | how | 09:03 |
| seb128 | well I didn't kill it | 09:03 |
| didrocks | oh* | 09:03 |
| pitti | right | 09:03 |
| seb128 | g-c-c thinks there is no hardware | 09:04 |
| pitti | seb128: output of "rfkill list"? | 09:04 |
| seb128 | 1: dell-bluetooth: Bluetooth | 09:04 |
| seb128 | Soft blocked: yes | 09:04 |
| seb128 | Hard blocked: no | 09:04 |
| pitti | there you go | 09:04 |
| pitti | that's the thing that the inidicator should look at | 09:04 |
| seb128 | shrug | 09:04 |
| pitti | seb128: you can enable it in g-c-c | 09:04 |
| seb128 | how did I do that? | 09:04 |
| seb128 | no I can't | 09:04 |
| pitti | hm, I can | 09:04 |
| seb128 | g-c-c says I've no hardware | 09:04 |
| seb128 | hum, it's acting weird | 09:05 |
| pitti | seb128: "rfkill unblock 1" | 09:05 |
| seb128 | if I toggle the switch it just goes back to disabled | 09:05 |
| seb128 | that worked | 09:05 |
| didrocks | seb128: does it display the indicator then? | 09:05 |
| didrocks | seb128: there is a bug I noticed between the indicator and g-c-c | 09:05 |
| seb128 | didrocks, no, but I disabled that, I don't need the indicator | 09:05 |
| pitti | seb128: right, that's what g-c-c is supposed to do; it does that here, even if it goes back to "disabled" | 09:06 |
| didrocks | if you turn it on in g-c-c, it goes back like 80% to disable | 09:06 |
| Laney | good day systemd fans | 09:06 |
| didrocks | if you use the indicator, it updates its status | 09:06 |
| didrocks | hey Laney! | 09:06 |
| pitti | yeah, the indicator grays out if you disabled BT in the current session, but it doesn't appear at all if you boot with BT hard or soft killed | 09:06 |
| seb128 | didrocks, pitti, is any of you looking to the "go back to disable"? | 09:06 |
| didrocks | seb128: I don't think it's systemd, I got it with upstart | 09:06 |
| seb128 | is that bug filed? | 09:06 |
| seb128 | didrocks, I didn't say it was, but you seem to know about it | 09:06 |
| didrocks | I was thinking it was blueman + indicator at the time | 09:06 |
| seb128 | didrocks, so I was curious if it was filed/being debugged | 09:06 |
| pitti | no, the difference with systemd is merely that saving state across reboot actually works | 09:06 |
| seb128 | pitti, ^ | 09:07 |
| didrocks | and I just killed blueman to see if that was the cause, it wasn't | 09:07 |
| pitti | whereas with upstart it doesn't -- it always comes back enabled (at least here) | 09:07 |
| seb128 | no everything has to do with systemd :p | 09:07 |
| seb128 | we should still fix bugs | 09:07 |
| pitti | seb128: yes, absolutely | 09:07 |
| pitti | seb128: I filed a related bug many months ago, hang on | 09:07 |
| seb128 | thanks | 09:07 |
| didrocks | seb128: I can open the bug, I have just vague reproducer steps though and didn't look at it in detail, just mentionned it in the bluez session | 09:07 |
| seb128 | didrocks, seems like pitti already did ;-) | 09:08 |
| pitti | ah, bug 1126108 | 09:08 |
| didrocks | seb128: I bet it's an indicator + g-c-c kind of thing | 09:08 |
| ubot5 | bug 1126108 in indicator-bluetooth (Ubuntu) "Indicator disappears entirely when disabling / turning off bluetooth" [Medium,Fix released] https://launchpad.net/bugs/1126108 | 09:08 |
| didrocks | hum | 09:08 |
| seb128 | didrocks, oh, I remember that one, it's a different issue | 09:09 |
| pitti | still the very same description/symptom, apparently this either regressed, or wasn't fixed completly | 09:09 |
| seb128 | the one I was speaking about is that the g-c-c control goes back to disabled when you try to enabled bt | 09:09 |
| didrocks | seb128: you disabled the indicator and you still have it? | 09:09 |
| seb128 | pitti, the issue was discussed a bit on robert_ancell's mp iirc | 09:09 |
| didrocks | (it being the bug) | 09:10 |
| pitti | seb128: ah; no, I didn't file one for that | 09:10 |
| pitti | seb128: it feels like it doesn't wait long enough for BT to appear or something such | 09:10 |
| seb128 | didrocks, no, I disabled showing the icon, the indicator is still running | 09:10 |
| didrocks | seb128: I just chmod -x the indicator and killed it | 09:10 |
| didrocks | the bug is still there | 09:10 |
| seb128 | k | 09:10 |
| seb128 | didrocks, you know you can "stop indicator-bluetooth"? ;-) | 09:11 |
| seb128 | upstart management ftw | 09:11 |
| pitti | seb128: didrocks likes the blunt and heavy tools :) | 09:11 |
| didrocks | seb128: I'm using old school trick learnt from an ex-french guy :) | 09:11 |
| seb128 | lol | 09:11 |
| didrocks | so anyway, it's not the indicator which is resetting the status under g-c-c feets | 09:11 |
| seb128 | indeed not | 09:12 |
| didrocks | seems it's shooting itself in its feet | 09:12 |
| pitti | speaking of ex-french -- seb128, hoe goed spreek je Nederlands door nu? | 09:12 |
| didrocks | :) | 09:12 |
| seb128 | pitti, ik ben Sebastien | 09:12 |
| seb128 | danku | 09:13 |
| pitti | Ik hou van je! | 09:13 |
| seb128 | that's about what I learnt :p | 09:13 |
| seb128 | lol | 09:13 |
| * didrocks smells some google translate under this :) | 09:13 | |
| * pitti looks innocent -- what is this Gogle trans-late? | 09:14 | |
| mlankhorst | hah | 09:15 |
| didrocks | it's an early thingy | 09:15 |
| Laney | hoe gaat het | 09:15 |
| pitti | Laney: goed, dank je! | 09:16 |
| didrocks | seb128: seems to be quite an old bug: bug #1056947 | 09:18 |
| ubot5 | bug 1056947 in gnome-control-center (Ubuntu) "Cannot turn on bluetooth after turning it off from the indicator" [Low,Confirmed] https://launchpad.net/bugs/1056947 | 09:18 |
| * mlankhorst tries reading afrikaans and giggles | 09:18 | |
| seb128 | didrocks, indeed, thanks for checking | 09:19 |
| didrocks | https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1056947/comments/7 | 09:19 |
| didrocks | yw | 09:19 |
| * Laney reboots with systemd too | 09:23 | |
| * Laney doesn't want to be left out | 09:23 | |
| didrocks | Laney: tell us about your system state, if you are in degraded mode or not | 09:24 |
| Laney | and actually I use /e/n/i on my desktop :-) | 09:24 |
| didrocks | old school guy! | 09:24 |
| didrocks | seb128: what do you think about desktoppers not using n-m? :) | 09:25 |
| Laney | needed a bridge interface for lxc | 09:25 |
| Laney | LXC!!!!! | 09:25 |
| didrocks | :) | 09:25 |
| seb128 | lol | 09:25 |
| seb128 | didrocks, be nice to old people | 09:26 |
| pitti | Laney: the default one doesn't do? I use LXC all the time | 09:26 |
| seb128 | ;-) | 09:26 |
| didrocks | heh | 09:26 |
| Laney | pitti: I wanted it to get real IPs on my LAN (+ avahi, etc), does it do that now? | 09:26 |
| pitti | Laney: ah no, the automatic virbr0 is just a 10.0.3.0/24 | 09:26 |
| Laney | nod | 09:27 |
| pitti | Laney: anyway, it should work just fine, did it? | 09:27 |
| Laney | dist-upgrading first | 09:27 |
| pitti | Laney: err, I mean lxcbr0, not virbr | 09:29 |
| pitti | it doesn't even add a global IPv6 address, sheesh! | 09:29 |
| Laney | oh noes, Errors were encountered while processing: | 09:30 |
| * Laney looks at this first | 09:30 | |
| Laney | gnome-flashback | 09:30 |
| Laney | mitya57!!!!! | 09:30 |
| GunnarHj | Hi pitti! | 09:55 |
| === ara_ is now known as ara | ||
| Laney | ah, good to see Lennart's face | 10:19 |
| Laney | and now we're booted | 10:19 |
| Laney | didrocks: so what is degraded mode? | 10:19 |
| didrocks | Laney: systemctl status | grep State | 10:19 |
| Laney | running | 10:20 |
| didrocks | sweet, no failure then :) | 10:20 |
| Laney | it took a while, might have been fscking or something | 10:20 |
| Laney | no plymouth to tell me | 10:20 |
| didrocks | yeah, this is known | 10:21 |
| didrocks | otherwise, just try basic system like bluetooth and so on, and ensure it's working :) | 10:21 |
| didrocks | but not having any units failing is already something | 10:21 |
| Laney | don't have any fancy hardware there | 10:22 |
| Laney | except the webcam? | 10:22 |
| Laney | holy shit, cheese is segfaulting | 10:22 |
| * Laney runs | 10:23 | |
| didrocks | it doesn't here, let me upgrade gstreamer :) | 10:23 |
| Laney | seems gtk-3.14-ish | 10:23 |
| Laney | I get a ton of criticals | 10:23 |
| Laney | seb128: confirm/deny? | 10:24 |
| didrocks | ok, I'm on 3.12 | 10:24 |
| seb128 | Laney, xfm | 10:25 |
| seb128 | wfm even | 10:25 |
| seb128 | no critical | 10:25 |
| Laney | with 3.14? | 10:27 |
| seb128 | yes | 10:28 |
| Laney | what | 10:29 |
| seb128 | WHAT | 10:29 |
| Laney | you capture my thoughts precisely | 10:29 |
| Laney | http://paste.ubuntu.com/9092839/ that's G_DEBUG=fatal-criticals | 10:30 |
| larsu | uh oh icon view | 10:36 |
| Laney | you have clue? | 10:38 |
| larsu | no, but icon view is notoriously bad to find issus in | 10:39 |
| larsu | this only started happening with systemd? | 10:40 |
| Laney | haha | 10:40 |
| Laney | I only tried it just now | 10:40 |
| Laney | could it really be that? | 10:40 |
| larsu | unlikely | 10:40 |
| seb128 | no | 10:41 |
| larsu | just asking after glancing at the scrollback | 10:41 |
| seb128 | I'm using systemd as well :p | 10:41 |
| Laney | we're all so futuristic | 10:41 |
| seb128 | Laney, does it happen if you unset gtk_modules? | 10:41 |
| seb128 | do you have o-s enabled? | 10:41 |
| Laney | criticals yes, segfault no | 10:41 |
| seb128 | just asking, because who knows | 10:42 |
| larsu | Laney: the bt you linked is a critical as well. Where's the crash? | 10:42 |
| Laney | it doesn't happen when I gdb | 10:43 |
| seb128 | weird | 10:43 |
| Laney | lemme see if apport got a dump | 10:43 |
| Laney | yes | 10:43 |
| Laney | libjpeg‽ | 10:44 |
| larsu | neat - seems unrelated to the cell_area one... | 10:44 |
| Laney | this trace is not entirely helpful | 10:44 |
| Laney | http://paste.ubuntu.com/9093045/ | 10:46 |
| larsu | hm, indeed not | 10:48 |
| Laney | 3.14 fixes the criticals but not the crash | 11:08 |
| mitya57 | Laney: oh, I did add Breaks, but to the wrong binary package. Thanks for fixing it! | 11:39 |
| Laney | mitya57: I didn't delete the old ones, you might want to do that. Wasn't going to fully understand the updates in order to work that out. :) | 11:40 |
| mitya57 | I see, will delete in next upload. | 11:41 |
| Laney | 'kay | 11:41 |
| larsu | " | 14:11 |
| larsu | I'm not an expert, but I don't think I need 114 instances of indicator- | 14:11 |
| larsu | sound-service." | 14:12 |
| seb128 | larsu, lol | 14:26 |
| seb128 | kenvandine, hey | 14:26 |
| seb128 | kenvandine, trying to backport most of trunk changes back to rtm? do you need some help there? | 14:26 |
| kenvandine | seb128, done already :) | 14:27 |
| kenvandine | just getting them ready so we can work on them one at a time as the bugs get approved | 14:27 |
| seb128 | kenvandine, done with everything, we can go home? ;-) | 14:27 |
| kenvandine | for ota-1 | 14:27 |
| kenvandine | haha | 14:27 |
| kenvandine | yeah, there are no more bugs, ever :) | 14:27 |
| seb128 | \o/ | 14:28 |
| kenvandine | seb128, did you enjoy the MP spam? :-p | 14:28 |
| seb128 | kenvandine, did! I bounced some back your way | 14:30 |
| seb128 | kenvandine, we need to figure out a strategy for string changes | 14:30 |
| kenvandine | yes.. we do | 14:30 |
| kenvandine | seb128, we've let some string changes in vivid, and at some point vivid is going to rtm :) | 14:31 |
| kenvandine | roll baby roll! | 14:31 |
| seb128 | kenvandine, that's fine since by that time vivid is going to have updated langpacks | 14:33 |
| seb128 | kenvandine, which is not the case of rtm if we land one of your settings changes | 14:33 |
| kenvandine | indeed | 14:33 |
| kenvandine | 2 of them i think | 14:33 |
| kenvandine | but, they said we are going to update the langpacks in rtm | 14:34 |
| kenvandine | we just need to coordinate that with the string changes | 14:34 |
| seb128 | well, how do you coordinate? | 14:34 |
| seb128 | you need the new template to be in place before generating the langpacks | 14:34 |
| seb128 | otherwise they are not going to include the correct translations | 14:34 |
| kenvandine | i think olli decided the string changes would be for ota-1, we just need to make sure the langpacks get generated after landing | 14:34 |
| kenvandine | yeah, generate them after landing and before images | 14:35 |
| seb128 | well, as long as it happens | 14:35 |
| seb128 | we should probably flag all string changes | 14:35 |
| kenvandine | i suggested we plan all the packages that have string changes to land at the same time | 14:35 |
| seb128 | and have a special day where we land all those | 14:35 |
| seb128 | then do langpack exports | 14:35 |
| kenvandine | yup | 14:35 |
| seb128 | ;-) | 14:35 |
| kenvandine | that's what i suggested | 14:35 |
| * seb128 ^5 kenvandine | 14:35 | |
| seb128 | didrocks, pitti, where/how do we define display-manager.service to be lightdm and what would be the way for a sysadmin to change that to e.g gdm? | 14:51 |
| seb128 | is that an alternative still? where is the magic? ;-) | 14:51 |
| pitti | seb128: it hasn't changed really -- debconf and /etc/X11/default-display-manager | 14:52 |
| pitti | it can't change either (it's reeealy complex), as we need to stay compatible to sysvinit and upstart | 14:52 |
| seb128 | pitti, I was just wondering what handles /etc/systemd/system/display-manager.service | 14:53 |
| seb128 | to make it point to the right service | 14:53 |
| pitti | seb128: that's in {lightdm,gdm,...}.postinst | 14:54 |
| pitti | seb128: they check debconf and make this link point to your selection | 14:54 |
| seb128 | pitti, ok, because I just installed xdm | 14:54 |
| didrocks | pitti: speaking of which, again something quite incompatible with the "default distro not in /etc" | 14:54 |
| seb128 | and selected in debconf to make it default | 14:54 |
| seb128 | and /etc/systemd/system/display-manager.service still points to lightdm.service | 14:54 |
| seb128 | didrocks, ^ | 14:55 |
| didrocks | seb128: probably not patched, mind opening a bug, I can look at this? | 14:55 |
| pitti | seb128: I think I only tried that with gdm3 and lightdm (kdm is also patched now); right, probably it needs to learn about this, too | 14:55 |
| seb128 | didrocks, debian has https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759005 | 14:56 |
| ubot5 | Debian bug 759005 in xdm "xdm: Missing xdm.service, can't use with systemd" [Wishlist,Open] | 14:56 |
| seb128 | though it's slightly different | 14:56 |
| seb128 | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748668 as well | 14:56 |
| ubot5 | Debian bug 748668 in slim "slim: Under systemd, randomly hijacks default-x-display-manager ignoring default selection" [Important,Open] | 14:56 |
| didrocks | seb128: yeah, a little bit, I'll look at both | 14:56 |
| seb128 | didrocks, thanks | 14:56 |
| didrocks | yw, see you found desktop-work on systemd :) | 14:57 |
| seb128 | hehe | 14:57 |
| seb128 | not sure we should spend much time making random dms work | 14:57 |
| seb128 | but I guess it's something we should fix if it's not too much work | 14:57 |
| didrocks | yeah, shouldn't be that much | 14:58 |
| didrocks | and I'll use that as a way to think about the empty /etc case | 14:58 |
| didrocks | (even if not applying for now) | 14:58 |
| === m_conley_away is now known as m_conley | ||
| maxb | I have a weird issue with CUPS (Printers added with the lpadmin command line produce strange errors on system-config-printer). Is this a sensible channel to look for help in filing a useful bug, or is there a better one? | 15:40 |
| seb128 | tkamppeter, ^ | 15:42 |
| larsu | maxb: best place is probably #openprinting on this server. What are the errors you're getting? | 15:42 |
| larsu | seb128: beat me :P | 15:42 |
| seb128 | ;-) | 15:42 |
| maxb | Attempting to access the properties page for a device added with lpadmin results in "There was a problem connecting to the CUPS server.". Running system-config-printer with --debug doesn't seem to show anything that would indicate the problem's source | 15:43 |
| larsu | maxb: is CUPS running? | 15:44 |
| maxb | Yes; devices added using the system-config-printer UI can have their properties pages viewed fine | 15:45 |
| maxb | Strangely, using "Duplicate" on a problem device in the UI produces a copy which does not experience the same problem. I've attempted to deduce what the difference is by studying the contents of /etc/cups/ but have been unable to locate an issue | 15:45 |
| larsu | maxb: very weird. Please try to talk to tkamppeter or twaugh (here or in #openprinting) | 15:46 |
| maxb | ok | 15:46 |
| tkamppeter | maxb, if you are able to print on your lpadmin-generated print queue and the only problem of it is to access its "Properties" window on system-config-printer, then report a bug on Launchpad, for the system-config-printer package. Tim Waugh will see the report and ask you further questions for debugging it. | 15:54 |
| maxb | tkamppeter: printing doesn't work either, I was just using the properties page as something easy to reproduce | 15:57 |
| tkamppeter | maxb, what error message do you get when you print something from the command line, using the "lp" or "lpr" command? | 15:59 |
| maxb | Hmm, that's interesting, printing from "echo foo | lpr" worked, whilst printing from Chrome just waited indefinitely with nothing happening | 16:00 |
| tkamppeter | maxb, in which stage does Chrome's printing hang? When opening the print dialog or when clicking "Print" inside the print dialog? | 16:06 |
| maxb | At the point of clicking the final "Print" button. It doesn't hang as such in that it can still be closed, but nothing happens even when waiting for quite some time | 16:07 |
| tkamppeter | Does the print dialog close when clicking on "Print" and the job does not come out or does the dialog stay open looking like CUPS is not answering to the click on "Print"? | 16:08 |
| maxb | Printing from gedit works, if that helps narrow anything down | 16:08 |
| tkamppeter | maxb ^^ | 16:09 |
| maxb | The second - dialog is mostly greyed out after clicking print, apart from the "Cancel" button | 16:09 |
| maxb | That was with Chrome's custom application print dialog. I just tried the same using "Print using system print dialog" - the dialog closed after clicking Print, and the job appears to have never been submitted | 16:11 |
| tkamppeter | maxb, is it only Chrome which does not print or are there other applications? | 16:11 |
| maxb | Just tried Thunderbird - that worked | 16:12 |
| maxb | Hmm, a second try of Chrome-using-system-dialog seems to have worked, so maybe the problems are confined to apps attempting to query cups about printers in some way | 16:15 |
| maxb | Oh great, the behaviour of my system appears to have changed. | 16:18 |
| maxb | Now I get "Unable to get queue details. Treating queue as raw." when opening the properties window for BOTH the UI-configured device and the CLI-configured device | 16:18 |
| tkamppeter | maxb, please report two bugs on Launchpad, one on system-config-printer for your problem with the "Properties" dialog, a second one on cups for the problem with Chrome (add chrome-browser as a second task). To both add an appropriate error_log as described on https://wiki.ubuntu.com/DebuggingPrintingProblems, section "CUPS error_log". For creating the one about the print dialog of Chrome, follow also the instructions of "R | 16:18 |
| tkamppeter | eporting Bugs". | 16:18 |
| * maxb will give it a go. Currently CUPS is failed to save settings after I tick the "Save debugging information for troubleshooting" box. | 16:21 | |
| maxb | Perhaps a reboot would be wise at this point | 16:22 |
| maxb | The good(?) news is that after a reboot the bug is back to the original presentation and I am able to turn on the debug options | 16:29 |
| maxb | Erm, the excitement continues, apparently I'm out of inodes because my /tmp is full of millions of symlinks to nonexistent PPD files | 16:49 |
| maxb | ARGH | 16:57 |
| maxb | Right | 16:57 |
| maxb | tkamppeter: Apparently "There was a problem connecting to the CUPS server." means "I can't open the PPD file as user maxb because it's mode 750 root:lp" | 16:58 |
| maxb | And this is the issue for Chrome too | 16:59 |
| desrt | hi hi desktopers | 17:00 |
| seb128 | hey desrt, how are you? had a good few days off work? | 17:04 |
| seb128 | didrocks, pitti, that systemd update fixed the failed ifup units issue, confirmed after an upgrade/reboot, thanks | 17:04 |
| didrocks | seb128: nice! | 17:08 |
| didrocks | hey desrt :) | 17:08 |
| mitya57 | bregma: are you taking care of lp:~albertsmuktupavels/compiz/support-libmetacity-private-3-14? | 17:09 |
| didrocks | pitti: ok, I have another proposal (upstream) for the alternatives in systemd. I'll wait to hopefully get some answers on the current one maybe first | 17:09 |
| bregma | mitya57, yes indeed, it's awaiting a ci-train silo assignment | 17:09 |
| mitya57 | ok, thanks | 17:09 |
| didrocks | pitti: I'm happy to expose it to you though :) | 17:09 |
| Sweet5hark | clang plugins are awsome. | 17:24 |
| Sweet5hark | ... if you are a bit morbid, it finds you bool ? true : false statements containing >60 individual statements including other conditional operators. Or assignments that contain other assignments and also are containing more than 50 individual statements. yay for sideeffects .... | 17:28 |
| didrocks | pitti: actually, my proposal is implemented in systemd looking at the code, so I guess it makes sense! I will just propose a way we change how we handle this to be more declarative | 17:40 |
| pitti | didrocks: which one now? the want.d/ or machine-id, or something else? | 17:45 |
| didrocks | pitti: how we do handle alternatives, like display manager, I need to go out soon, but I'm happy to talk to you about it tomorrow morning (finishing up some end of day cleanup tasks) | 17:48 |
| seb128 | oh, just a fyi I've a day off tomorrow | 17:49 |
| seb128 | in case somebody wonders why I'm not around | 17:49 |
| seb128 | I'm back on friday | 17:49 |
| pitti | didrocks: yeah, me too; just came back quickly upon an SMS :) | 17:49 |
| pitti | seb128: enjoy! | 17:50 |
| seb128 | pitti, thanks! | 17:50 |
| didrocks | see you on Friday seb128! :) | 17:51 |
| seb128 | didrocks, have a good evening! | 17:51 |
| Sweet5hark | seb128: have fun! (and when you are back, consider uploading the libreoffice pkg for vivid) ;) | 17:51 |
| didrocks | thanks | 17:52 |
| Sweet5hark | s/consider/please consider/ | 17:52 |
| seb128 | Sweet5hark, hey, you didn't reply to my ping from yesterday about the version bump, did you? | 17:52 |
| seb128 | Sweet5hark, upload is blocked on that to happen on your side | 17:52 |
| seb128 | Sweet5hark, or did you update since and I missed your ping about it? | 17:52 |
| Sweet5hark | seb128: hmm, must have missed that. whats missing? | 17:53 |
| seb128 | Sweet5hark, the version you put up for sponsoring is already in utopic-updates and it can't exist with different builds in different series | 17:54 |
| seb128 | Sweet5hark, we can't copy the binaries because of the libpoppler abi change in vivid | 17:54 |
| seb128 | Sweet5hark, so you need at least to bump the version to 0ubuntu2 | 17:54 |
| Sweet5hark | seb128: ah, ok. willdo. | 17:54 |
| seb128 | thanks | 17:54 |
| Sweet5hark | seb128: have fun on your day off! | 17:55 |
| seb128 | Sweet5hark, thank you! | 17:55 |
| === alan_g is now known as alan_g|EOD | ||
| * willcooke -> EOD | 18:11 | |
| willcooke | *mic drop* | 18:11 |
| === m_conley is now known as m_conley_away | ||
| RAOF | desrt: Hey, dude. Where's the place to go to propose a new desktop item field? | 23:11 |
| desrt | xdg list | 23:11 |
| desrt | what did you have in mind? | 23:11 |
| desrt | i might be able to save you some time by telling you why you won't get what you want :) | 23:11 |
| RAOF | Sure. | 23:15 |
| RAOF | I want a Needs-GPU: field. | 23:15 |
| RAOF | With... some contents. | 23:15 |
| desrt | you're not going to get that :) | 23:15 |
| desrt | why do you want it? | 23:16 |
| RAOF | Hybrid graphics | 23:16 |
| desrt | you might be interested in TryExec= | 23:16 |
| RAOF | No, that's not going to help. | 23:16 |
| desrt | it's the name of a utility program to run to decide if the desktop file in question should be displayed or not | 23:16 |
| RAOF | The shell wants a way to know whether or not to start this application on the discrete chip or whether the integrated chip is ok. | 23:16 |
| desrt | hm. | 23:17 |
| desrt | that's a bit more interesting. | 23:17 |
| RAOF | eg: Games always want the fastest chip, totem won't care. | 23:17 |
| desrt | does it affect the libGL that gets linked or something? | 23:17 |
| RAOF | Implementation dependent. | 23:17 |
| desrt | heh | 23:17 |
| RAOF | But on the free stack it's basically setting the DRI_PRIME environment variable. | 23:17 |
| desrt | my answer to you would be to figure it out at runtime | 23:17 |
| RAOF | How can the shell figure this out at runtime? | 23:18 |
| desrt | not the shell -- the just-started app | 23:18 |
| RAOF | How does the just-started app respect your powersaving prefernces? | 23:18 |
| desrt | presumably we would have some library component in there responsible for the decision making | 23:18 |
| RAOF | This sounds super-complicated vs Wants-GPU: Fastest / Wants-GPU: don't care | 23:19 |
| desrt | considering that the general trend right now is moving over to using dbus activation to launch apps via systemd, the shell isn't going to be able to control the environment that this happens under anyway | 23:20 |
| desrt | also: it wouldn't only be the shell in any case... imagine an app that gets started on account of a file association from nautilus (or firefox, or anything else...) | 23:20 |
| RAOF | Incidentally, why is the general trend towards starting apps via dbus activation over systemd? | 23:21 |
| desrt | for a lot of reasons | 23:22 |
| desrt | mostly because apps are increasingly being seen as services, only one feature of which is "please launch now" | 23:24 |
| desrt | other features might be "please do something appropriate in response to this push notification" or "please reply to the shell's search query" | 23:24 |
| desrt | another reason is because it means that apps are always started in a clean environment, as a direct child of the session manager, able to be monitored and in their own cgroup | 23:24 |
| desrt | instead of as a fork() off of whatever random app wanted to open text/plain without really caring who got called | 23:24 |
| RAOF | This has a certain charm. | 23:24 |
| RAOF | But what I'm hearing here is that I want to patch systemd :) | 23:24 |
| desrt | i think what really needs to happen is that the app needs to tell the system on startup (ie: at the time of initialising GL) "i want the big one" | 23:25 |
| desrt | although i understand that the our diverse landscape of drivers from not-entirely-cooperative vendors might make that difficult to do | 23:25 |
| RAOF | I always love boil-the-oceans solutions :) | 23:25 |
| desrt | well, eventually the ocean will boil | 23:26 |
| desrt | these things can sometimes happen pretty quickly | 23:26 |
| desrt | meanwhile, maybe use a wrapper script or something | 23:26 |
| desrt | Exec=hardcore-graphics /path/to/original/exe | 23:26 |
| RAOF | That doesn't really satisfy my goal of “this information should be upstream” | 23:27 |
| desrt | where that hardcore-graphics thing consults [whatever] and sets environment variables as needed | 23:27 |
| desrt | ya... you gotta boil the ocean for that :) | 23:27 |
| desrt | but seriously, though.... how do we handle this? | 23:27 |
| RAOF | Currently? | 23:27 |
| RAOF | We don't, at all. | 23:27 |
| desrt | right | 23:28 |
| RAOF | Hybrid graphics remains the preserve of the nerdy. | 23:28 |
| desrt | you have one thing called libGL | 23:28 |
| desrt | and it is what it is | 23:28 |
| RAOF | Actually... I'm not sure that's true. I think the *proprietary* drivers actually have some semblance of reasonable user interface. But I've not used them. | 23:28 |
| desrt | i wonder if something like libepoxy could help | 23:30 |
| RAOF | Well, the “we have one thing called libGL” (a) isn't a problem for the free stack, and (b) is getting fixed by a new Linux GL ABI. | 23:30 |
| desrt | that's really more of a consumer-side helper, though | 23:30 |
| RAOF | Right. | 23:31 |
| desrt | but this sort of pointer trickery is what i have in mind | 23:31 |
| desrt | GL people love that crap | 23:31 |
| desrt | you can switch out the entire guts of the implementation on them at runtime :) | 23:31 |
| desrt | ...at least it would help to substantially reduce the amount of manual indirection you are responsible for maintaining... | 23:33 |
| RAOF | So, design goals: The app should be able to say “give me the awesome one”, the desktop should be able to determine which one the app gets. | 23:34 |
| desrt | i think the way the app should do this is with a call to some function early in main() before GL is initialised | 23:34 |
| desrt | this call might well be setenv() | 23:34 |
| desrt | it's certainly not -too- difficult to imagine a fake libGL that connects you with a different real implementation under it depending on some random things determined at runtime | 23:35 |
| desrt | you could even make it based on ifuncs... | 23:36 |
| desrt | (although those are known to have issues with environment varaibles and they might be 'too early' to be useful to you) | 23:37 |
| RAOF | I guess it's much easier if you drop the “shell should have control” requirement. | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!