[04:43] <pitti> Good morning
[06:11] <larsu> good morning!
[06:33] <didrocks> good morning
[06:35] <didrocks> pitti: hey! yeah, I think we have to blacklist nodm then, I'm unsure about the kdm case still, let me try to install it on my vm
[06:35] <didrocks> as the binary matches
[06:35] <pitti> bonjour didrocks!
[06:35] <pitti> didrocks: ah, so you already saw my CC:s
[06:36] <pitti> didrocks: also, seems Lennart was on a review/reply sprint :)
[06:36] <pitti> didrocks: so you got a very good review already for your machine-id patches, that's great! :-)
[06:36] <didrocks> pitti: oh nice! I'm not to that point yet :)
[06:38] <larsu> morning didrocks, pitti!
[06:39] <didrocks> hey larsu
[06:43] <pitti> hey larsu
[07:00] <didrocks> pitti: tried to install kdm on this vm, no issue, all states are what is expected
[07:00] <pitti> didrocks: yeah, I asked for a systemctl status, we didn't get that yet
[07:00] <pitti> didrocks: the nodm issue is quite clear, I think
[07:01] <pitti> but not kdm
[07:01] <didrocks> pitti: indeed, let me see if I can find a way for nodm than the blacklist
[07:01] <pitti> didrocks: btw, could this grow an autopkgtest perhaps? installing three DMs, and then selecting between them?
[07:02] <didrocks> pitti: I guess so, it will involve dpkg-reconfigure and such (and maybe testing the 3 postinst at the same time), do we have examples of autopkgtests with this?
[07:02] <seb128> good morning desktopers
[07:02] <seb128> hey pitti didrocks
[07:02] <didrocks> salut seb128
[07:02] <pitti> bonjour seb128, ça va ?
[07:02] <seb128> pitti, oui, un peu fatigué mais ça va, et toi ?
[07:03] <pitti> seb128: j'ai dormi très bien (alors seulement à 5h30 :) )
[07:04] <pitti> didrocks: you can install packages during the test with apt-get, or test-depend on all three of them and then perhaps change /e/X/d-d-m and call dpkg-reconfigure, or cause the generators to re-run and check the result, or so
[07:05] <pitti> didrocks: you can also reboot to verify that the DM actually starts up (systemd's boot-and-services autopkgtest does that for lightdm)
[07:05] <pitti> didrocks: but even if it isn't a full system integration test with reboot, merely changing the config file and seeing that the generators are as expected should be fine
[07:05] <pitti> didrocks: anyway, the nodm thing is quite clear, and we'll wait for the kdm bug (moreinfo)
[07:06] <didrocks> pitti: yeah, systemctl status is the only way to see what happens…
[07:06] <didrocks> pitti: on the integration testing -> will try to do something, but polishing the other patch on Lennart's feedback first
[07:06] <pitti> didrocks: yes, it's low-priority
[07:07] <didrocks> funny that nodm ship an insserv.conf.d file, but doesn't check for default display-manager
[07:07] <pitti> didrocks: also, I guess this whole generator will go away in jessie+1 again once the *dm packages get fixed properly?
[07:07] <didrocks> pitti: the insserv patch will
[07:07] <didrocks> not the other one (as long as we have /e/X/d-d-m
[07:07] <didrocks> )
[07:07] <didrocks> but the other one is less "magic", it's just making display-manager.service matching /e/X/d-d-m
[07:08] <didrocks> (and don't mask units)
[07:09] <didrocks> pitti: the issue is that if someone just systemctl enable --force <dm_service>, as it's not updating /e/X/d-d-m  (maybe we should) for dms, it's not really taken into account.
[07:10] <didrocks> as the generator will override this next round
[07:10] <pitti> didrocks: yeah :/ too many knobs
[07:10] <didrocks> but well, in the past, people already dpkg-reconfigure to make /e/X/d-d-m piloting which dms to start, so it's not a big change
[07:10] <didrocks> pitti: agreed, I wonder if we should drop some of those support in ubuntu
[07:10] <didrocks> (I know, not really possible in debian)
[07:11] <pitti> but I think /e/X/ddm should always win, as that happens to be Debian's main config for DM selection
[07:11] <didrocks> yeah, that's the case now
[07:11] <didrocks> or you can remove it, and systemctl controls the default then
[07:11] <didrocks> (once all units are transitionned)
[07:11] <pitti> didrocks: and that's fine; but it shouldn't cause your only installed DM to not run, so that must be something else?
[07:12] <didrocks> right
[07:12] <didrocks> anyway, let's blacklist nodm for now, and wait on the kdm's bug some feedback
[07:13] <pitti> didrocks: if you need anythign else aside from status, please followup to the bug
[07:13] <pitti> and we should probably downgrade it, as it's not reproducible
[07:13] <didrocks> pitti: I'm juts doing that
[07:13] <didrocks> downgrade?
[07:13] <pitti> didrocks: Control: severity -1 important
[07:13] <didrocks> ok
[07:13] <pitti> Control: tag -1 moreinfo (but I think it already has that)
[07:52] <didrocks> pitti: hum, still don't get the systemctl status on last answer, so let's see if other reports the same thing with kdm
[07:53] <pitti> didrocks: meh, yes
[07:53] <pitti> didrocks: do you want to respond again, or should I?
[07:54] <didrocks> pitti: I'm doing it
[07:55] <didrocks> done
[07:58] <seb128> didrocks, pitti, speaking about status, I've that
[07:58] <seb128> ● NetworkManager-wait-online.service loaded failed failed Network Manager Wait O
[07:58] <seb128> is that expected/something to debug?
[07:59] <pitti> seb128: hm, I think I got that yesterday, not today; sometimes my wifi is slow to connect
[08:00] <didrocks> seb128: maybe running systemctl status NetworkManager-wait-online.service as root will give you more info
[08:00] <didrocks> (journald output at the end)
[08:00] <didrocks> (success for me btw)
[08:01] <pitti> and yes, sometimes it takes more than one minute on my system (the timeout in that unit is 30s)
[08:01] <didrocks> waow
[08:01] <didrocks> ah right --timeout=30
[08:02] <pitti> but this unit looks broken anyway
[08:02] <pitti> WantedBy=network.target → sohuldn't that be network-online.target?
[08:02] <didrocks>  pitti hum, his kdm.service is masked :/
[08:02] <pitti> like in systemd-networkd-wait-online.service
[08:03] <didrocks> pitti: I'm having hard time on parsing this network systemd wiki page on freedesktop
[08:03] <didrocks> so unsure :)
[08:03] <pitti> seb128: anyway, it's worth reporting eiter way; we don't want degraded units if we can avoid it
[08:04] <seb128> didrocks, http://paste.ubuntu.com/9341619/
[08:04] <pitti> if possible, NM should be taught to get faster
[08:04] <seb128> pitti, reported against what? nm?
[08:04] <pitti> seb128: yes
[08:04] <seb128> k
[08:04] <seb128> danke
[08:04] <pitti> my mobile needs < 1 s for connecting to my wifi, my laptop some 50 s
[08:05] <pitti> not sure how that behaves for other people, but over the last few cycles NM became really slow for wifis
[08:05]  * pitti had to bump the timeouts in the autopkgtest at leaset twice
[08:05] <seb128> it seems to vary a lot here
[08:07] <seb128> didrocks, pitti, so you think the issue there is that it hit the timeout?
[08:07] <pitti> seb128: yes
[08:07] <didrocks> seb128: should be, I don't have that issue. Bad that the output debug doesn't state it explicitely :/
[08:08] <pitti> well, unless nm-online -q --timeout=30 is differently broken of course
[08:08] <didrocks> maybe dropping -q would help…
[08:08] <pitti> yeah, I think this shoudl drop the -q
[08:08] <seb128> should I edit the service and wait for next time it happens and see what's the issue?
[08:08] <didrocks> pitti: nm-online --timeout=30
[08:08] <didrocks> -> no output, exit 0 in the success case
[08:09] <didrocks> so, maybe we should really drop it to have more info in case of failure
[08:09] <pitti> seb128: yeah, and correlate it to whether it's already online or not right after boot
[08:09]  * didrocks is puzzled on Eric's answer
[08:09] <pitti> seb128: you can play with the timeout, too; i. e. bumping it to 60 should make it succeed, 5 should make it fail always?
[08:10] <seb128> pitti, k, I'm going to try that, thanks
[08:10] <pitti> seb128: cheers!
[08:11] <seb128> I booted my laptop at a coffee place yesterday and it took ages to connect, so it's likely the timeout
[08:12] <pitti> it's mostly a cosmetical issue anyway (nothing depends on network-online.target, and that unit sorts wrongly anyway)
[08:13] <pitti> so I think it's ok for that particular unit to fail especially on a laptop, but it should be fixed anyway (wants dependency, and dropping -q)
[08:14] <pitti> and maybe bumping the timeout to reflect NM's/dhcp-client's slowness
[08:14] <seb128> k
[08:14] <seb128> that makes sense
[08:14] <seb128> pitti, thanks
[08:14] <pitti> seb128: did you notice other problems?
[08:15] <seb128> no
[08:15] <seb128> I didn't notice much difference either
[08:15] <seb128> which I guess is good ;-)
[08:15] <pitti> it is :)
[08:19] <pitti> didrocks: so maybe a strange effect of having a separate /usr?
[08:19] <pitti> didrocks: and the generator runs before mounting it, or so?
[08:20] <didrocks> pitti: there is nothing that I'm using on /usr though
[08:21] <didrocks> pitti: I just removed all dms but kdm here
[08:21]  * didrocks reboot
[08:21] <didrocks> pitti: the only thing I can think of is a trailing \n on /e/X/d-d-m
[08:21] <didrocks> but I'm stripping it :/
[08:22] <didrocks> hum, works…
[08:23] <pitti> didrocks: systemd-delta output or some ls -l /etc/... perhaps? there might be some unexpected symlinks somewhere?
[08:23]  * pitti -> doctor appointment, bbl
[08:24] <didrocks> pitti: yeah, doing that
[08:29] <seb128> hum, another libpam-systemd apport report during an upgrade, are those common issues?
[08:54] <willcooke> morning
[08:55] <didrocks> hey willcooke
[08:58] <larsu> morning willcooke
[09:00] <seb128> hey willcooke
[09:03] <willcooke> We should have an "office" Christmas party in here before Christmas.
[09:03] <willcooke> )
[09:03] <willcooke> :)
[09:05] <larsu> ☃
[09:05] <seb128> hehe
[09:22] <pitti> seb128: no, not at all; report svp?
[09:23]  * pitti hugs didrocks, isn't debugging fun
[09:24]  * didrocks hugs pitti back, yeah, I have no clue on that one, I'm implementing Lennart's proposals meanwhile and will appreciate if you can have a look before resubmitting :)
[09:26] <seb128> pitti, bah, apport says it can't report because the package is not installed, which is not true
[09:26] <pitti> le huh?
[09:27] <seb128> pitti, https://errors.ubuntu.com/oops/38476d4e-7a05-11e4-80de-fa163e4ccdf2
[09:27] <seb128> not very useful
[09:28] <pitti> seb128: that's bug 1372193
[09:28] <seb128> pitti, the log has http://paste.ubuntu.com/9342363/
[09:29] <pitti> seb128: yep, exactly the same
[09:30] <pitti> that's slangasek's
[09:30] <pitti> seb128: he posted some questions there, if you currently have that problem answering those might be helpful
[09:31] <seb128> pitti, just did
[09:31] <pitti> cheers
[09:32] <pitti> we got the first instance of this in natty already, but then just two duplicates
[09:32] <pitti> so it seems old, but hard to reproduce
[09:32] <seb128> k
[09:32] <seb128> I've hit a few times on vivid
[09:32] <seb128> I wonder if it doesn't happen at every systemd update for me
[09:33] <pitti> seb128: can you attach /etc/pam.d/common-session as well, for completeness?
[09:34] <seb128> pitti, done
[09:34] <pitti> seb128: btw, should we re-enable apport for vivid now?
[09:34] <pitti> (LP crash bugs, I mean)
[09:34] <pitti> I'm about to do an upload for some fixes
[09:34] <seb128> pitti, your call, I don't have a strong opinion on it
[09:35] <seb128> pitti, I've the feeling that nowadays we have few people keep up with launchpad and that reports create more noise than they are useful
[09:35] <pitti> ok; I'll leave it off for now, still a bit early
[09:35] <pitti> seb128: yeah, same here
[09:43]  * didrocks rebase on new improved systemd logic now for error handling then
[09:44] <seb128> pitti, good news is that I can reproduce that bug easily, I just need to dpkg -i an old systemd and use update-manager to upgrade
[09:44] <seb128> just tried
[10:05] <didrocks> pitti: mind giving a look before I update the ML?
[10:05] <didrocks> http://people.canonical.com/~didrocks/tmp/systemd-machine-id-commit/0005-machine-id-commit-add-man-pages.patch
[10:06] <didrocks> http://people.canonical.com/~didrocks/tmp/systemd-machine-id-commit/0002-Add-a-machine_id_commit-call-to-commit-on-disk-a-tra.patch
[10:06] <didrocks> http://people.canonical.com/~didrocks/tmp/systemd-machine-id-commit/0001-Factorize-some-machine-id-setup-functions-to-be-reus.patch
[10:06] <didrocks> pitti: forget the 0005-, this one didn't need change, wrong paste :)
[10:07] <didrocks> pitti: already noticed, I need to remove +#include <linux/magic.h> and +#include <sys/statfs.h> from 0002
[10:09] <pitti> didrocks: 1 LGTM
[10:09] <pitti> didrocks: 2> the latter will "be" mounted ...
[10:09] <pitti> didrocks: and "get reset" at each bot
[10:09] <pitti> boot
[10:10] <pitti> didrocks: latter -> later
[10:10] <didrocks> fixing
[10:11] <pitti> didrocks: later, "this can commit the transient machine-id to disk in a race free manner"
[10:11]  * pitti apologizes for being a grammar fetishish
[10:11] <pitti> fetishist
[10:11] <didrocks> ahah, it's good, don't worry :)
[10:11] <pitti> I have a good excuse, both of my parents were teachers, my mother was a German teacher :)
[10:12] <didrocks> heh :)
[10:13] <pitti> didrocks: Lennart asked for the if (isempty(root)) thing?
[10:13] <pitti> i. e. strappenda doesn't treat NULL as ""?
[10:13] <pitti> or using strappenda(root || "", "/etc/machine-id") is too magic?
[10:13] <didrocks> pitti: why later btw? I'm referencing /etc/machine-id?
[10:14] <pitti> didrocks: "becomes rw later"
[10:14] <pitti> didrocks: as opposed to "the latter will be..."
[10:14] <didrocks> pitti: I did that at first, and noticed that he was doing the isempty() stuff just some line below with the same logic
[10:14] <pitti> (which is a reference to a previous enumeration)
[10:14] <didrocks> pitti: I thought they wanted to avoid in the common case to have the strappenda() call
[10:14] <pitti> didrocks: ah, good, then keep that
[10:14] <didrocks> pitti: ah ok, indeed :)
[10:15] <pitti> didrocks: "was an independent mount" → what's that?
[10:15] <pitti> as opposed to being a slave bind mount or so?
[10:15] <didrocks> pitti: like /etc/machine-id is a mount point (not /etc)
[10:16] <pitti> didrocks: ah, I was wondering about the "independent"; so perhaps s/independent mount/mount point/?
[10:16] <didrocks> pitti: yeah, sounds more explanatory, changing
[10:16] <ogra_> independent is the "post revolutionary mountpoint" indeed
[10:17] <pitti> ogra_: no more slave mounts!
[10:17] <didrocks> :)
[10:17] <ogra_> !
[10:17] <pitti> didrocks: S_ISREG(st.st_mode) -> why that additional check, as long as you can read from it?
[10:17] <didrocks> ogra_: well, that's why I make-rslave later on :p
[10:18] <pitti> didrocks: ah, probably safer; it could be a socket which blocks
[10:18] <didrocks> pitti: exactly, for sockets
[10:18] <didrocks> or dirs
[10:18] <pitti> didrocks: why do you sometimes use log_error_errno() and sometimes just log_error with %m? (I don't know the former yet, and what the difference is)
[10:19] <didrocks> pitti: that's part of the modifications, see http://lists.freedesktop.org/archives/systemd-devel/2014-December/025783.html (near the end)
[10:19] <didrocks> they introduced that between my first patch and now
[10:19] <pitti> didrocks: machine_id_commit() will run in a separate binary, not in pid 1, right?
[10:20] <didrocks> pitti: right, patch 3 introduces a binary for it
[10:20] <pitti> didrocks: oh, log_errror_errno() gets the "r" as arg, I see
[10:20] <didrocks> yeah, and seems it's thread-safe compared to strerro(r)
[10:21] <pitti> didrocks: ok, I'm done complaining
[10:21] <didrocks> I looked at the #define pragma, but a little bit too magical to me to understand why this one is threadsafe where the other isn't
[10:21] <didrocks> \o/
[10:21] <didrocks> pitti: thanks for the suggestions, just wrapping that and sending :)
[10:29] <didrocks> pitti: hum, any idea why the dates are all screwed up in my format-patch?
[10:29] <didrocks> Mon Sep 17 00:00:00 2001
[10:29] <pitti> didrocks: uh, no; they are usually correct for me
[10:30] <didrocks> pitti: ah, I have the answer in the man, no worry :)
[10:39] <seb128> didrocks, pitti, I wonder if there is not really a problem with systemd/n-m, I've had 3 boots now where I needed to turn the switch on and off to be able to connect
[10:39] <seb128> didrocks, pitti, http://paste.ubuntu.com/9343059/ ... not much more without the -q
[10:41] <willcooke> seb128, I have the school run @ 1520 UTC.  I should be back in time for the weekly meeting, but if I'm not would you mind getting it started?
[10:41] <seb128> willcooke, sure can do
[10:41] <willcooke> thanks seb128
[10:41] <seb128> yw
[10:43] <didrocks> seb128: that happened since 217? (you didn't complain on 215 about having to switch on and off)
[10:44] <seb128> didrocks, yeah, I didn't notice it before today
[10:44] <seb128> not sure when I rebooted previous, a week ago or so I guess
[10:44] <seb128> I can go back to 215 to test if you want
[10:44] <didrocks> seb128: that and try to boot with upstart as well
[10:45] <didrocks> just to ensure it's a systemd regression
[10:45] <seb128> k
[10:45] <seb128> brb
[10:59] <seb128> didrocks, pitti, yeah, it's 217 that creates the issue, and it creates it for upstart as well as systemd used as init
[10:59] <seb128> could be udev or something
[11:00] <seb128> with 215 I'm online before unity7 UI is done loading
[11:00] <seb128> with 217 I need to turn network off and on other it never connects
[11:10] <Sweet5hark1> seb128: sorry for causing confusion when juggling with bug ids when should have stayed in bed and fight of the cold ...
[11:10] <Sweet5hark1> s/of/off/
[11:10] <seb128> Sweet5hark1, no worry, do you feel better btw?
[11:11] <Sweet5hark1> seb128: yes, today Im ok again.
[11:11]  * seb128 doesn't believe in staying in bed and doing nothing when having a cold, prefer to keep a bit busy to get his mind off the cold :p
[11:11] <seb128> Sweet5hark1, great :-)
[11:14] <Sweet5hark1> seb128: well,  I also did https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=66fc18538b544d62bc51f2fc485cf997433ff990;hp=ef5051b59270b324968cb91304fb25f622b80329 ff. -- making one of the most fundamental base container classes of LibreOffice Writer a template class etc.
[11:14] <Sweet5hark1> seb128: we will see in LibreOffice 4.5 how badly I broke stuff with that ;)
[11:17] <Sweet5hark1> seb128: I can tell you though a 34" 21:9 ultrawide screen at your workplace helps fighting off the flu quicker though ;D
[11:18] <seb128> hehe
[11:31] <Sweet5hark1> seb128: updated bug 1386170 for SRU-foo. While doing that, I noted there is no customer feedback yet (see comment 11) ...
[11:31] <seb128> Sweet5hark1, looking
[11:32] <seb128> Sweet5hark1, looks good, thanks
[12:06] <didrocks> pitti: we can avoid hardcoding, see my answer from Michael's questions
[12:13] <pitti> didrocks: but yeah, this is highly nontrivial, and at this point I'm not sure any more whether we really want to inflict this upon ourselves
[12:14] <pitti> didrocks: i. e. this turns bugs which are really in the *dm packages into systemd bugs, and apparently doesn't catch some more exotic configs?
[12:19] <didrocks> pitti: well, remember that we did this in reaction of other bugs like "multiple dms starts due to systemd"
[12:20] <didrocks> or none if the config isn't in sync
[12:20] <pitti> yeah, I know
[12:20] <pitti> rock <-> hard place
[12:20] <didrocks> pitti: let's try the fix I proposed, I think that would help
[12:20] <didrocks> (meaning, touching less if /e/X/d-d-m isn't correct)
[12:35] <didrocks> pitti: btw, apt-get install nodm fails
[12:35] <didrocks> invoke-rc.d seems to try to call systemctl enable without an unit file
[13:57] <deepdreamer> hello, i have question about updates. If i use lts version of ubuntu (14.04), will i receive updates for unity that are not just security updates (but also bugfixes) after 14.10 was released?
[13:59] <deepdreamer> just want to know whether i have to abandon lts (14.04) to have newest version of unity 7
[14:07] <didrocks> pitti: the nodedm case isn't due to my generator
[14:07] <didrocks> pitti: the insserv generator isn't called on it
[14:08] <didrocks> and look at the status, it's not masked
[14:08] <pitti> didrocks: hm, so why did it break with 217-1 then?
[14:09] <didrocks> pitti: maybe something else in systemd? I'm unsure, but it's clearly not called or I'm missing something…
[14:10] <seb128> didrocks, pitti, did you see my note about the connection issue being a regression from 215->217 and impact upstart boots as well as systemd ones? need more info from me on that one?
[14:10]  * didrocks rechecks again
[14:10] <pitti> didrocks: ok, thanks for investigating; the generator seemed to be the most probable cause at first, sorry for the noise then
[14:10]  * seb128 downgrades to system 215 meanwhile
[14:10]  * xnox loves how 217 at times finds a dependency loop and removes units and does not start them at all =)
[14:10] <didrocks> seb128: yeah, I have no clue about this
[14:11] <pitti> seb128: perhaps rather downgrade udev for now, to verify that?
[14:11] <seb128> didrocks, do you know what changed between those versions and maybe if I should try to revert changes?
[14:11] <didrocks> pitti: let me reconfirm again, but I'm printing at startup of the function and the insserv isn't called
[14:12] <didrocks> seb128: I'm on another urgent issue for now (with as well debates), so preferring to concentrate on this
[14:12] <seb128> dpm, hey, can you get https://translations.launchpad.net/ubuntu/vivid/+source/ubuntu-ui-extras to have a bumped priority/to be visible for ubuntu touch translators?
[14:12] <seb128> didrocks, well, the network issue impacts vivid users on upstart (e.g not only people opting in for systemd), but ok
[14:13] <didrocks> *sigh*
[14:16] <seb128> k, meeting is in a bit more than hour, going for exercice and then I'm going to try to downgrade udev only
[14:16] <seb128> but that might be after the meeting
[14:16] <seb128> bbl
[14:16] <pitti> seb128: yeah, please file a bug to keep track of what you downgraded/experimented with, and what happens after booting
[14:16] <pitti> seb128: i. e. whether NM comes up, NM syslog, etc.
[14:16] <seb128> k
[14:17] <pitti> and if it's udev, we also need to compare udevadm info --export-db between 215 and 217, etc.
[14:17] <pitti> seb128: I'm not aware of any big changes in udev, so I'm afraid for now I don't have an idea where to start; we need some logs from your machine
[14:18] <pitti> seb128: enjoy the exercise!
[14:18] <seb128> pitti, ok, thanks, I'm out for an hour getting some exercice before night/meeting time, but I get those info when I'm back
[14:18] <seb128> pitti, danke
[14:18] <seb128> I assume I'm the only one so far to report those issues?
[14:18] <seb128> if that's specific to my config that's probably not a big issue
[14:18] <didrocks> nothing on debian bts
[14:18] <seb128> still I would like to get to the bottom of it, so let's see what info I can get
[14:19] <pitti> seb128: yes, I didn't get any bug reports or IRC pings from someone else, and it's obviously working here
[14:20] <pitti> seb128: yes, I'd like to debug that too
[14:21] <didrocks> pitti: so, I added log_warning("checking %s", de->d_name); after http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/insserv.conf-generator.patch#n428
[14:21] <didrocks> pitti: I only have gdm3 and kdm printing, where the directory contains as well nodm and rpcbind
[14:22] <funky> i want to enable compiz fusion in my ubuntu. i downloaded and installed all the necessary tools and plugins. yet it is not working. pls help
[14:23] <Guest55607>  working. pls help
[14:23] <Guest55607>  i want to enable compiz fusion in my ubuntu. i downloaded and installed all the necessary tools and plugins. yet it is not working. pls help
[14:23] <Guest55607> anybody there??
[14:24] <didrocks> Guest55607: !topic
[14:24] <didrocks> (For support please join #ubuntu)
[14:25] <Guest55607> but nobody is replying to my question there
[14:26] <didrocks> pitti: oh, maybe it's the generator with a silent return code !=0, let me try :)
[14:27] <didrocks> pitti: that would explain everything then: others dms are not iterated over and so, not inserted under the x-display-manager target
[14:28] <Guest55607> helooo
[14:52] <didrocks> larsu: I think I have an issue with strappenda actually
[14:52] <didrocks> defaultdm_unit_path = strappenda(SYSTEM_DATA_UNIT_PATH, "/", default_dm, ".service");
[14:52] <didrocks> with static const char *default_dm = NULL;
[14:52] <didrocks> (cached outside the function)
[14:52] <didrocks> and _cleanup_free_ char *defaultdm_unit_path = NULL; from within the function
[14:53] <didrocks> I'm getting a double free corruption if I let that instruction
[14:53] <larsu> how does strappenda know that you pass it 4 arguments? (I assume it's a vararg function?)
[14:55] <larsu> ah, it's a macro that inlines __VA_ARGS__ into an array. Neat.
[14:55] <didrocks> yeah #define strappenda(a, ...)                                       \
[14:55] <larsu> didrocks: anyhow, don't free() something you allocated with alloca
[14:55] <didrocks> larsu: I don't free anything
[14:55] <didrocks> at least, not explicitely :
[14:55] <larsu> didrocks: _cleanup_free_ marks it for free()ing
[14:55] <didrocks> :)
[14:56] <didrocks> larsu: ahhhhh, making sense, I thought it was preparing it
[14:56] <larsu> didrocks: yep, welcome to c99 :)
[14:56] <didrocks> larsu: I need to read this one day :)
[14:56] <didrocks> larsu: thanks a lot!
[14:56] <larsu> it's pretty cool, but most projects don't make use of it because they want to work on !gccc
[14:56] <larsu> *gcc
[14:56] <didrocks> pitti: FYI, so that was part of the cause, I'll add my fix now ^
[14:57] <didrocks> larsu: yeah, I bet…
[14:57] <pitti> didrocks: ah, I faintly remember asking about strappenda() getting along with NULL strings :)
[14:57] <pitti> didrocks: great!
[14:58]  * didrocks rebuilds, retests, etc.
[14:58] <larsu> pitti: probably not, the macro calls strlen() on the strings
[15:07] <dpm> seb128, done, ubuntu-ui-extras has now the same priority (8500) as ubuntu-ui-toolkit
[15:24] <GunnarHj> pitti: ubuntu-docs was just built in utopic-proposed, so I think I've done my part before the langpacks update.
[15:30] <seb128> dpm, thanks
[15:31] <willcooke> #startmeeting Desktop Weekly Meeting 2014-12-02
[15:31] <meetingology> Meeting started Tue Dec  2 15:31:06 2014 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:31] <meetingology> Available commands: action commands idea info link nick
[15:31] <seb128> willcooke, hey ;-)
[15:31] <willcooke> Roll Call:  attente_, desrt, didrocks, FJKong, larsu, mlankhorst, qengho, seb128, Sweet5hark1, tkamppeter
[15:31] <didrocks> hey
[15:31] <Sweet5hark1> heya
[15:31] <willcooke> Sorry I'm late all, had to do the school run
[15:31] <qengho> dang!
[15:32] <willcooke> attente_, hey, are you ready to roll, or shall we come back to you?
[15:32] <seb128> o/
[15:32] <willcooke> in the interests of brevity, lets come back to attente_ and move on to desrt
[15:32] <willcooke> #topic desrt
[15:33] <attente_> gdk-mir backend:
[15:33] <attente_> some investigation into multiple window apps, need support from mir for surface positioning, might not be available till jan
[15:33] <attente_> fix a bug with text selection
[15:33] <attente_> er. sorry
[15:33] <willcooke> :)
[15:33] <attente_> add a hack for making menus and transient dialogs clickable
[15:33] <willcooke> nw
[15:33] <willcooke> this is great, thanks attente_
[15:34] <willcooke> desrt, you want to go?
[15:35] <desrt> sure
[15:35] <desrt> did a lot of running around, meetings, bug-filing about missing mir features for desktop
[15:35] <desrt> fixed semi-serious GMainContext bug (thanks to ppc64le and Laney for finding it)
[15:35] <desrt> finished off GVariant vector serialisation work (see https://git.gnome.org/browse/glib/log/?h=wip/gvariant-kdbus for info)
[15:35] <desrt> still a lot more GVariant work to do to prepare for kdbus -- follow the branch linked above
[15:35] <desrt> starting on internal cleanup of GBytes (GVariant's memory tracking structure)
[15:35] <desrt> (fin)
[15:35] <willcooke> thanks desrt
[15:36] <willcooke> #topic didrocks
[15:36] <didrocks> Ubuntu developer desktop:
[15:36] <didrocks> * Some reviews and fixes for jayatana (appmenu integration for java applications) to be integrated by default on ubuntu. Need upstream to put a last fix and cut a tarball.
[15:36] <didrocks> * Started discussion on pip/rubygem with sudo
[15:36] <didrocks> Bluez:
[15:36] <didrocks> * Put back packages to the transition ppas to have them built on all archs
[15:36] <didrocks> * Tested with Mathieu that bluez5 + pulseaudio integration is working
[15:36] <didrocks> * Started investigating some of the package transitions (bluemon, blueman, …) The good news is that most of them don't need anything!
[15:36] <didrocks> Systemd:
[15:36] <didrocks> * Fix using generators how default DM are handled and have only one started, being or not migrated to systemd
[15:36] <didrocks> * Get previous week patch (for empty machine-id) feedbacks + done some modifications. Waiting for a rereview
[15:36] <didrocks> * Started to look X failsafe handling and possible implementation using systemd services
[15:36] <didrocks> EOF
[15:37] <willcooke> sounds like bluez is moving forwards nicely
[15:37] <willcooke> thanks didrocks
[15:37] <willcooke> didrocks, any idea how many potential names we had for the UDTC ?
[15:37] <willcooke> *have
[15:37] <didrocks> willcooke: I would say like 20-25, I did repost on g+ for the second week of the contest
[15:38] <willcooke> wow - that's really good
[15:38] <didrocks> not a lot of +1 on any name though, we will have to vote ourself I guess :)
[15:38] <willcooke> haha!
[15:38] <willcooke> #topic FJKong
[15:38] <willcooke> FJKong, are you around atm?  We can come back to you if not
[15:38] <FJKong> Dash pinyin progress: coding for converting Chinese character to pinyin
[15:38] <FJKong> tgenerate a mapping table between PinYin and character
[15:38] <FJKong> splite Chinese character (ignoring english words)
[15:38] <FJKong> get all candidate lis
[15:38] <FJKong> all about pinyin thing
[15:38] <FJKong> eof
[15:39] <willcooke> :)
[15:39] <willcooke> nice progress there, thanks
[15:39] <willcooke> #topic larsu
[15:39] <larsu> hey!
[15:40] <larsu> more work on the gtk theme, the blockers should be gone now, but there's still some work left
[15:40] <larsu> (e.g. highlighting the current tab for willcooke ;) )
[15:40] <seb128> do you have a mp up with the current work? do you consider it enough for a first landing?
[15:41] <seb128> (we should get it at least in the ppa with gtk)
[15:41] <larsu> seb128: I want to land it in lockstep with gtk and need to sort out the icon issue before that
[15:41] <seb128> k
[15:41] <larsu> which brings me to that point: I hate the xdg icon spec
[15:41] <seb128> well, we have gtk in the desktop ppa, we can put the theme there as well
[15:41] <seb128> :-/
[15:41] <larsu> a recent gtk change made some svg icons in menus larger (calendar, gvim in the dash)
[15:42] <larsu> seb128: sure, we can do that
[15:42] <seb128> cool
[15:42] <larsu> also fixed an issue in gsettings (no changed events were sent)
[15:42] <willcooke> larsu, that tab highlighting works nicely for gedit but for gnome-terminal I find it confusing - by brain inverts the logic for which is the current tab for some reason.  I'll have a play with colours and such
[15:43] <larsu> willcooke: we could override tabs for each app, but I'd rather not have more app-specific theming
[15:43] <larsu> (fin)
[15:43] <willcooke> larsu, agreed.  I'll have a play and see if I can reach a happy medium
[15:43] <willcooke> #topic mlankhorst
[15:43] <willcooke> mlankhorst, lots of Xmir work this week :)
[15:44]  * qengho cheers.
[15:45] <willcooke> hm, mlankhorst must be afk, he was here a moment ago.
[15:45] <willcooke> nevermind, we can come back
[15:45] <willcooke> #topic qengho
[15:45] <qengho> * done: new flash update. new chromium upstream released, but not worth new U package. thanksgiving.
[15:45] <qengho> * in-progress: more Cr/mir hacking. upstream Ozone interface churns *so much*. Angry qengho.
[15:45] <qengho> some hardware problems, too, but you can't help with that.
[15:45] <qengho> EOF
[15:46] <willcooke> qengho, did you see my mail re: Hi DPI - when you get a moment please drop me a reply - but not super urgent
[15:46] <qengho> willcooke: Haven't seen it. Will search.
[15:46] <willcooke> thx
[15:46] <willcooke> #topic seb128
[15:46] <seb128> (4 days week, vac on thurday)
[15:46] <seb128> • discussions about how to handle .desktop renames for dbus activable softwares
[15:46] <seb128> • debugged issues with qtcreator/sdk/ssh/click publishing to the device on vivid
[15:46] <seb128> • spent some time playing with mir/mir_server to get more familiar with that part of the stack
[15:46] <seb128> • spent some time playing with systemd and ran into some bugs
[15:46] <seb128> • ubuntu-system-settings for touch
[15:46] <seb128> ∘ small reviews for others
[15:47] <seb128> • some sponsoring
[15:47] <seb128> • usual share of desktop related bugs triages and discussions

[15:47] <willcooke> thanks seb128
[15:47] <willcooke> #topic Sweet5hark1
[15:47] <Sweet5hark1> - still work on 4.3.4/4.2.7 SRUs and bugs 1386170, bug 1342175 and the 4.2 Calc sort mess (to many bug ids to list)
[15:47] <Sweet5hark1> - followed upstream discussion on possible 4.2.8 release
[15:47] <Sweet5hark1> - finally released first build of 4.4.0~beta1 for vivid to prereleases ppa after much patching and tweaking
[15:47] <Sweet5hark1> - 4.4.0~beta1 l10n is still FTBFS (not urgent though, betas have incomplete l10n anyway)
[15:47] <Sweet5hark1> - upstream discussion on baseline/compiler update for more C++11 for LibreOffice 4.5 ff.
[15:47] <Sweet5hark1> - upstream discussion on folding URE to libreoffice-core
[15:47] <Sweet5hark1> - some coordination of upcoming LibreOffice events: Hamburg (end December -- 31c3), Brussels (begin February 2015, FOSDEM), Gran Canaria (March), Cambridge (May)
[15:47] <Sweet5hark1> - clarified REFERENCEOOMAJORMINOR confusion upstream (this is about which version of
[15:47] <Sweet5hark1>   OpenOffice.org LibreOffice claims to impersonate to extensions)
[15:47] <Sweet5hark1> - some coordination on LibreOffice mobile(Android) tender (which also enables completing the gtk3 engine, more OpenGL rendering)
[15:47] <Sweet5hark1> - some considerations on the long-term supportability of LibreOffice 3.5.x on precise
[15:47] <Sweet5hark1> - refactored some fundamental Writer container class from 1980ies code to pull it screaming and kicking into this century (constness, templateing, typesafety, kill macros)
[15:47] <Sweet5hark1> - some flu downtime
[15:47] <Sweet5hark1> - running on extrawide productivity now: got myself a 34" 21:9 screen
[15:48] <willcooke> Sweet5hark1, I'll try and get over to Cambridge for a day in May  - it's just down the road from me
[15:48] <Sweet5hark1> willcooke: awesome!
[15:48] <willcooke> #topic tkamppeter
[15:49] <tkamppeter> - OpenPrinting web server: Several fixes in database maintenance scripts
[15:49] <tkamppeter> - system-config-printer: Download mostly working again
[15:49] <tkamppeter> - hplip: HPLIP team is testing IPP-over-USB.
[15:49] <tkamppeter> - Bugs.
[15:49] <willcooke> good news on the driver download, thanks tkamppeter
[15:50] <willcooke> #topic robert_ancell
[15:50] <willcooke> Worked on:
[15:50] <willcooke> - Released Unity Greeter 15.04.0, 15.04.1
[15:50] <willcooke> - More code working for TPM support
[15:50] <willcooke> - Started porting gnome-bluetooth to Bluez 5
[15:50] <willcooke> - Updated gnome-calculator to 3.12
[15:50] <willcooke> - Upstreamed gnome-bluetooth patches
[15:50] <willcooke> Currently working on:
[15:50] <willcooke> - TPM support
[15:50] <willcooke> - Bluez 5 support
[15:50] <willcooke> #topic TheMuso
[15:50] <willcooke> * Packaged up Pulseaudio 6.0 RC 1 aka 5.99.1. It was initially uploaded to the Ubuntu desktop team bluez5 PPA, and was moved to the transitions PPA ppa:ubuntu-desktop/transitions.
[15:50] <willcooke> * Also built armhf packages, and they can be found at http://people.canonical.com/~themuso/pulse-5.99-bluez5-armhf/.
[15:50] <willcooke> * Discussed with Debian about where Ubuntu pulseaudio packaging will be hosted going forward, it was agreed to put it in a branch as part of the pkg-pulse alioth team git packaging repo.
[15:50] <willcooke> * Pushed the packaging of 5.99.1 to Debian's git repo as a result of sed discussion.
[15:50] <willcooke> * Upgraded to vivid, no show stopper issues for me personally, will spend some time testing the latest pulse going forward, and plan to package newer RC releases as they are made available.
[15:51] <willcooke> #topic any other business
[15:51] <willcooke> Lots of things in progress right now, but nothing solid to report on, probably will have more details next week
[15:52] <willcooke> mlankhorst, FJKong - are you guys around atm?
[15:53] <FJKong> willcooke: atm?
[15:53] <willcooke> FJKong, you want to give your update?
[15:53] <willcooke> #topic FJKong
[15:53] <FJKong> I already give my update...
[15:54] <willcooke> oh
[15:54] <willcooke> yes
[15:54] <willcooke> of course
[15:54] <FJKong> pinyin thing..
[15:54]  * willcooke is having too many simultaneous conversations 
[15:54] <willcooke> in which case
[15:54] <willcooke> #endmeeting
[15:54] <meetingology> Meeting ended Tue Dec  2 15:54:39 2014 UTC.
[15:54] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2014/ubuntu-desktop.2014-12-02-15.31.moin.txt
[15:56] <Sweet5hark1> ah, so freenode wasnt kidding and muted my last item for flooding ....
[15:57] <willcooke> oh - one more thing, I am going to be in the London office on Thursday , so will be travelling Thursday morning
[15:57] <desrt> Sweet5hark1: you were trying to write, in decimal, the number of minutes it took to build the new libreoffice?
[15:58] <Sweet5hark1> desrt: actually the line was: "#agreed Sweetshark should stop using MeetBots tags to confuse his co-workers"
[15:58] <desrt> :)
[15:59]  * desrt pastes one-line-at-a-time these days to avoid trouble
[16:00] <seb128> kenvandine, hey
[16:00] <seb128> kenvandine, do you plan to do some settings landing for rtm/ota?
[16:01] <didrocks> seb128: did you check the udev downgrade? I'm free for helping you now :)
[16:01] <kenvandine> seb128, yup
[16:02] <seb128> didrocks, no, came back like 1 min before the meeting and the issue happen on my work laptop so I couldn't reboot
[16:02] <didrocks> seb128: ok, keep me posted
[16:03] <didrocks> larsu: on the g-t thing, any chance so that we have a good bamf matching again on the terminal windows? (I saw you discuss it the other day, but didn't see the end of it I guess)
[16:04] <larsu> didrocks: it's on my list, just not very high, sorry
[16:05] <larsu> didrocks: I have the problem myself, so I'll probably get around to fixing it at some point this cycle ;)
[16:05] <didrocks> larsu: as long as it's on your list for vivid, I'm fine, I just don't think we should release in the current status
[16:05] <didrocks> larsu: heh ;)
[16:05] <didrocks> state* even
[16:05] <larsu> didrocks: I totally agree :)
[16:11] <mlankhorst> sorta
[16:26] <seb128> didrocks, pitti, downgrading udev/libudev fixes the issue
[16:26] <seb128> diff from udevadm info --export-db on http://paste.ubuntu.com/9346619/
[16:28] <seb128> wlan0 and some eth stuff changed
[16:31] <pitti> seb128: ah, thanks for confirming! can you please ubuntu-bug udev and attach that diff? I'll see what changed there and how to debug this further
[16:33] <seb128> pitti, sure, with the new udev installed I guess?
[16:33] <seb128> hum, syslog is spammed with such warnings
[16:33] <seb128> Dec  2 17:23:25 localhost systemd[1]: unit_create_cgroups -.slice: cgroup  exists already
[16:33] <seb128> Dec  2 17:23:25 localhost systemd[1]: unit_create_cgroups system.slice: cgroup /system.slice exists already
[16:33] <seb128> Dec  2 17:23:25 localhost systemd[1]: Failed to reset devices.list on /system.slice: Invalid argument
[16:33] <pitti> seb128: doen't matter that much
[16:33] <seb128> yeah, just trying to find useful infos and I've pages of those
[16:34] <pitti> seb128: right, but that should be unrelated and relatively harmless; if systemd 217 plus udev 215 fixes it, it's not that
[16:34] <pitti> seb128: you didn't happen to try systemd 215 plus udev 217, I suppose?
[16:35] <seb128> my syslog has no wlan0 with udev 217
[16:35] <seb128> pitti, no, but I can if you want
[16:36] <seb128> that's the boot with udev 217
[16:36] <seb128> Dec  2 17:23:25 localhost NetworkManager[740]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/virbr0, iface: virbr0)
[16:36] <seb128> with 215
[16:36] <pitti> seb128: I have these messages too; they are from an intermediate version of a patch to fix user LXC containers
[16:36] <seb128> Dec  2 17:25:07 localhost NetworkManager[757]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/net/wlan0, iface: wlan0)
[16:37] <seb128> the wlan0 line is missing with 217
[16:37] <pitti> seb128: do you have wlan0 in /etc/network/interfaces?
[16:37] <seb128> $ cat /etc/network/interfaces
[16:37] <seb128> auto lo
[16:37] <seb128> iface lo inet loopback
[16:37] <seb128> $
[16:37] <pitti> we usually don't on desktop and let NM manage it dynamically
[16:37] <seb128> pitti, ^
[16:38] <seb128> pitti, well, seeing http://paste.ubuntu.com/9346619/ wlan is missing
[16:38] <pitti> ah right, I have these too (lo, wlan0)
[16:38] <seb128> -P: /devices/pci0000:00/0000:00:1c.1/0000:02:00.0/net/wlan0
[16:38] <seb128> -E: DEVPATH=/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/net/wlan0
[16:38] <seb128> -E: DEVTYPE=wlan
[16:38] <pitti> seb128: yes, that diff is most useful
[16:40] <pitti> seb128: I don't have a virbr0, just an lxcbr0 (what lxc sets up); do you happen to know where that comes from?
[16:40] <seb128> pitti, no idea, maybe that has nothing to do with it
[16:40] <seb128> virtualbox I would guess from the name?
[16:40] <seb128> I use it
[16:41] <pitti> seb128: oh, waaaaaaaait
[16:41] <pitti>         * Userspace firmware loading support has been removed and
[16:41] <pitti>           the minimum supported kernel version is thus bumped to 3.7.
[16:41] <pitti> that smells a lot like your diff
[16:41] <pitti> +E: FIRMWARE=iwlwifi-6000-5.ucode
[16:41] <pitti> +E: SUBSYSTEM=firmware
[16:41] <pitti> +E: TIMEOUT=60
[16:41] <pitti> i. e. in that state the firmware isn't loaded yet
[16:42] <seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1398458
[16:43] <seb128> pitti, my kernel is 3.16.0-26-generic
[16:43] <pitti> [    6.586593] iwlwifi 0000:02:00.0: Direct firmware load failed with error -2
[16:46] <Sarvatt> i dont see iwlwifi-6000-5.ucode in any linux-firmware package
[16:47] <pitti> in dmesg I see [    2.898239] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm
[16:47] <pitti> so that's Centrino Advanced-N 6200 (your's) vs. 6205 (mine), shouldn't be totally different..
[16:49] <pitti> seb128: could you boot with "debug log_buf_len=1M"? maybe the kernel will be a bit more verbose about what fails?
[16:49] <seb128> pitti, where do I put that?
[16:50] <pitti> seb128: ah, kernel command line, i. e. in the "linux" line in grub
[16:50] <pitti> where you'd also have init= or  quiet and splash
[16:51] <seb128> k
[16:51] <seb128> pitti, waiting a few minutes in case apw has a better suggestion
[16:52] <seb128> going to make some tea meanwhile
[16:52] <pitti> seb128: mmmm, tea!
[16:52] <seb128> :-)
[18:36]  * willcooke -> EOD