=== slank is now known as slank_away [00:30] robert_ancell: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/972537/comments/16 ? [00:31] Ubuntu bug 972537 in unity-greeter (Ubuntu Precise) "lightdm doesn't allow expired passwords" [High,Fix committed] [00:35] again, using a Windows VM to access a Google Nexus phone because Linux can't do it. Well known problem though. [00:51] Should I create one bazar repo for each package version? (I am following http://developer.ubuntu.com/packaging/html/packaging-new-software.html) [00:53] slangasek, oh duh. Cheers :) === chiluk_away is now known as chiluk === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === EagleScreen is now known as Guest68724 === rafael is now known as Guest18012 === Ursinha is now known as Ursinha-afk [04:23] Good morning [04:25] hallyn: TBH I don't understand the problem -- how do udev's dynamic ACLs get in the way of static group permissions? [04:26] dobey: since yesterday, ubuntuone-syncd goes crazy, creates a million /tmp/tmp* files, and uses 100% CPU all the time [04:27] dobey: there hasn't been a new ubuntuone-client upload in a while; do you know what changed, and how to debug this? [04:30] pitti: if you setfacl group::--- /dev/kvm; chmod g+rw /dev/kvm; then ls -l will show ???rw-??? for /dev/kvm, but group owner won't actually have rw. so, the problem [04:30] is only when you isntall a new system and do 'apt-get install qemu-kvm' [04:31] bc udev won't remove that acl, so until you reboot group kvm can't use /dev/kvm [04:31] once you reboot, the acl doesn't get reinstalled, so it's ok after that [04:32] pitti: look at qemu-system.postinst and qemu-system.udev in raring's qemu for what we have to do to work around it [04:32] hallyn: the postinst only triggers udev to reapply its rules AFAICS [04:32] pitti: yes, and without adding an explicit setfacl to those rules, it's not enough [04:33] pitti: (which is why i pointed out the new qemu-system.udev; it's kind of ugly and unfortunate, and requires a depends from qemu on acl which wasn't there before) [04:34] hallyn: so you are saying that GROUP="kvm" doesn't actually work? [04:34] or that MODE="0660" doesn't? [04:34] pitti: well, ACTUALLY GROUP=kvm sometimes doesnt' work but that's another story, [04:34] MODE=0660 does work, but doesn't remove the acl [04:35] so you end up with file perms allowing g+rw, but acl denying it [04:35] yeah, it's not supposed to remove ACLs [04:35] well something has to [04:35] but ACLs ought to be additive, not remove permissions [04:35] they're additive in that they are always checked on top of the file perms, not in the "add more permission" sense :) [04:36] pitti: more to the point, though, there is no reason for a group acl ever, [04:36] the user acl is used by consolekit to allow the loggedin user to access /dev/kvm, but group acl is worthless, [04:36] hallyn: I thought the point of the ACLs was to allow the local active user to access it [04:36] so easiest just to remove it (as in my patch) [04:36] yes. user acl. [04:36] the group acl though is worthless [04:37] hallyn: so why does the udev rule add this group ACL in the first place? [04:37] dunno [04:37] it seems odd to me to introduce the RUN:="/usr/bin/setfacl -m g::rw $env{DEVNAME}" in the distro, and then add a patch to revert it [04:37] oh, i'm mis-stating what my patch does - doesn't remove the acl, just sets it to group::rw- [04:38] [04:38] i introduced that to workaroudn this udev bug [04:38] and want to remove it as soon as the udev bug is fixed [04:38] (also, I'm not sure that RUN:= actually does anything different than RUN=) [04:38] i'm not advocating keeping my changes to the qemu-system.udev in qemu source [04:38] i'm advocating simply adding GROUP=0660 to the 70-udev-acl.rules [04:39] so that /dev/kvm always gets group::rw- rather than group::--- acl [04:39] so I'm still confused -- why can't we just drop that odd RUN from /lib/udev/rules.d/40-qemu-system.rules ? [04:39] then qemu can ship a simple udev rules file to chgrp /dev/kvm to group kvm [04:39] that already sets the MODE correctly AFAICS [04:39] pitti: if we *just* drop that, then after install qemu-kvm (and until rebooting) group kvm can't access /dev/kvm [04:39] yes, but it's too late [04:40] that MODE only does chmod, not setfacl [04:40] bc udev is not smart enough to update the acl [04:40] hallyn: oh, you mean this is solely to fix the upgrade from that current .rules which sets that odd group ACL? [04:41] pitti: (if i understand you right) yes [04:41] hallyn: i. e. you are going to drop the RUN part in 40-qemu-system.rules, but you want it to work at instant? [04:41] right, [04:41] hallyn: that kind of thing is usually a job for the postinst [04:41] i'll go back to the old 40-qemukvm.rules [04:41] i. e. check the version you are upgrading from, and just call chmod [04:42] which iirc was jsut KERNEL=="kvm", GROUP="kvm", MODE="0660" [04:42] yeah, and that looks nice and clean [04:42] pitti: well i'm not sure about calling chmod - that's what debian does so i may go back to it, but slangasek prefers we do udevadm trigger... but either way the udev rule would like tobe KERNEL=="kvm", GROUP="kvm", MODE="0660" :) [04:43] pitti: so all i was really pinging you about was adding 'GROUP="0660"' for the kvm case to 70-udev-acl.rules [04:43] hallyn: calling trigger is fine, and should always be done on upgrade [04:43] pitti: it's fine, but it's currently insufficient :) [04:43] inotify is sucking [04:43] hallyn: and on upgrade to the next version, you just additionall call chmod [04:44] but again that (inotify) is a different problem [04:44] pitti: so do you have any objectio to adding 'GROUP="0660"' to 70-udev-acl.rules? :) [04:45] yes [04:45] as that potentially breaks custom rules, and also is the wrong place for one-time upgrade fixes [04:45] one-time? [04:46] well, it only applies for upgrades from <= 1.3.0+dfsg-1~exp3ubuntu7 (assuming that ubuntu8 will fix it) [04:46] group=--- for /dev/kvm (when owned by root:root) has zero advantages [04:46] pitti: this has nothing to do with any version of qemu-kvm, really [04:47] so its postinst shoudl call chmod on upgrades from those versions, and then be done with it [04:47] chmod is not enough [04:47] qemu did not wrongly label anything [04:47] every time you install an ubuntu system, [04:47] /dev/kvm gets set up (when someone logs in on consoel) with a group::--- acl, [04:47] hallyn: I thought /lib/udev/rules.d/40-qemu-system.rules was wrong (it certainly looks odd), and you were going to fix that? [04:47] which never gets cleared by udev (bc udev doesn't support that) [04:48] so apparently we still talk about completely different things then [04:48] pitti: if the udev bug gets fixed (which is what i'm pinging you about) then i'll simplify the 40-qemu-system.rules, yes. [04:48] udev does not add any group ACLs [04:48] that's only from that rule [04:49] hallyn: I still don't understand what the udev bug is here? [04:49] well, udev sets the initial perms, and then consolekti adds ana cl for it [04:49] the udev bug is that it sets group perms to --- instead of rw- [04:49] hallyn: ^ but that ACL has nothing to do with the one from 40-qemu-system.rules [04:49] no it has to do with 70-udev-acl.rules [04:50] i pointed you to 40-qemu-system.rules to show you how we have to work around the udev bug right now [04:50] (i originally did it as an explicit setfacl in qemu-system.postinst, but slangasek asked me to change that) [04:51] pitti: so one more time (since you've set me straight :), the order of events is: [04:51] ok, so back to my originally question: what _is_ the udev bug? [04:51] 1. set up a new ubuntu system, it modprobes kvm_intel, /dev/kvm gets created, [04:51] 2. 70-udev-acl.rules sets /dev/kvm to root:root rwx------, and tags it with acl [04:51] 3. user logs in, consolekit adds a group::--- acl [04:51] hang on, why root:root? [04:51] that should be root:kvm, as per 40-qemu-system.rules [04:51] because group kvm doesn't yet exist, [04:52] qemu-kvm has not yet been installed [04:52] ok [04:52] 4. admin logs in remotely, installs qemu-kvm, triggers udev, [04:52] 5. udev chowns /dev/kvm to root:kvm, and sets it to rwxrw----, [04:52] (qemu-system, BTW) [04:52] right [04:52] 6. libvirt tries to start a vm as group kvm, but the group:--- acl refuses it [04:53] I don't understand 3. [04:53] udev-acl only applies ACL_USER acls, it doesn't touch group ACLs [04:53] that's only from that weird 40-qemu-system.rules run rule [04:53] nope [04:54] i don't know why the acl gets added, but it has done it since at least q, [04:54] i only updated that 40-qemu-kvm.rules recently to work around it [04:54] it only does it when user logs in on console before qemu-kvm gets installed [04:55] but it's hit quite a few people over the past 6-12 months [04:55] so anyway, all that is to say that if the 70-udev-acl.rules shipped with udev would just set GROUP=0660, then the acl gets set as group::rw-, and all works out fine [04:55] but nowhere in udev's source code a group ACL is set [04:56] no, but somewhere (in the dank depths of consolekit iiuc) an acl gets set to mirror the perms udev has set [04:56] (well, and no, acls DO get set in udev code...) [04:56] that's /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck [04:56] (but i believe you that it isn't causing this acl) [04:56] * hallyn goes to look [04:56] hallyn: yes, udev-acl.ck sets user ACLs, but not group [04:57] so we need to understand where that group:--- ACL gets set in the first place, and eliminate that [04:57] that woudl be ideal [04:58] hallyn: so you are saying that group ACL had been set even before 40-qemu-system.rules got that RUN rule? [04:58] yes [04:59] that acl is there if you just boot a new ubuntu system without qemu-system installed, and log in on cnosole [04:59] pitti: you're sure udev-acl.c can't set that? [04:59] hallyn: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/udev/quantal/view/head:/extras/udev-acl/udev-acl.c is that code [05:01] hallyn: I don't see where it should set group ACLs, and that thing isn't supposed to [05:02] yeah doesn't look like it, good [05:02] hallyn: you can temporarily remove /lib/udev/rules.d/70-udev-acl.rules and /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck and check if that group ACL is still there, to be 100% sure [05:02] weird bugs are always possible, of course [05:03] pitti: or perhaps this is a time for systemtap (if it actually works in raring atm) [05:03] so IF udev-acl.ck sets a group ACL, then that's indeed a nasty bug [05:04] and what exaclty does /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck do? [05:05] (i can aim to test this tomorrow, but will need to find some space to test it :) [05:05] (i never did trust new-fangled consolekit :) [05:06] hallyn: it adds an rw ACL for the user that is on the currently active console, and removes ACLs for the previously active user [05:06] hallyn: for all devices which are tagged with UDEV_ACL [05:06] so if i *just* remove that that should be enough to test [05:06] hallyn: the idea being to allow the current foreground session access to things like sound cards, cameras, or said /dev/kvm, but deny it to background sessions or remote users [05:07] e. g. getfacl /dev/dri/card0 [05:07] user::rw- [05:07] user:martin:rw- [05:08] the second is what udev-acl.ck does; and if I switch user, or to VT1, I lose that again [05:08] (that makes more sense on a sound card or digicam, of course) [05:08] pitti: you're on raring? [05:08] yes [05:09] waht does getfacl /dev/console give you? [05:09] do you get group::--- ? [05:09] oh nm, that's not an acl in that instance [05:10] yes, but that's from normal unix perms? [05:10] right [05:10] /dev/kvm has [05:10] group::rw- [05:11] which might be either from the static unix permissions or from 40-qemu-system.rules (g::rw is the same, isn't it?) [05:12] pitti: right. [05:12] pitti: well if you have a raring iso handy to do a vmware install you can just give it a shot - but i've got to go, will see about udev-acl.ck tomorrow. [05:12] thanks - good ngiht [05:13] good night! [05:14] removing the acl won't revoke access, though; does consolekit kill -9 processes that have resources open? [05:16] no, it doesn't; that would be quite rude :) [05:18] perhaps; but perhaps someone holds a webcam open or something.. [05:19] I guess that's one more reason to put a piece of tape over webcams and microphone ports.. [05:19] heh [05:55] * hallyn pokes his head in just to remind sarnold real quick that we've been asking for revoke(2) syscall since around 2002 :) [05:56] hallyn: .. if not even earlier :) [06:34] I was on the look out for a C++ project in ubuntu so i can apply my programming skills [06:34] any help [06:44] alwin: a lot of stuff in Ubuntu seems to be done in Python or Vala nowadays [06:45] with the bigger dependency on GNOME. [06:45] alwin: check out U1, most of it is written in C++ using the Qt framework [06:49] Jack: what is U1 [06:51] Pretty much anything that depends on libqt will be C++ somewhere. [06:51] Plus all the Mozilla products. [06:51] LLVM. [06:51] Lots of stuff. [06:52] But if you're asking "what do we need help with?", the answer is "I dunno". Find a package you feel passionately about and check its bugs. [06:52] alwin, u1 = ubuntu one. [06:53] but i agree with infinity, find a package you're passionate about and start on the bugs in the package [06:53] (base)adconrad@cthulhu:~$ reverse-depends libstdc++6 | wc -l [06:53] 4695 [06:53] that's what happened to me, except i went down the bug triage direction, and kind of pseudo-adopted nginx :p [06:53] Should be some choices in those 4695 packages. :) [06:53] lol.... [06:53] 4695 packages... xD [06:53] infinity, is gcc one of those packages? :p [06:54] Of course. [06:54] figures :P [06:54] * TheLordOfTime is curious what you need to build gcc... *checks builddeps* [06:55] Rabbit hole it is then :) [06:55] TheLordOfTime: To build just the C compiler, you need precious little. The more languages you add, the more interesting it gets. [06:55] infinity, i meant gcc and the whole shebang that goes with the language :P [06:56] basically, "What is necessary to build all the GCC and related library packages" :P [06:56] (The only real gotcha for the C portion of GCC is that gcc/glibc are very tightly intertwined, and the bootstrap between the two is mildly entertaining) [07:14] alwin: U1 = Ubuntu One [07:14] sorry about that [07:14] upgrading to 13.04 :) [07:34] good morning [07:34] hey dholbach [07:35] hi pitti [07:48] hallyn: I responded to the bug again with a detailled analysis [07:56] hallyn: ah, saw your response, thanks! Will check that out [07:56] hallyn: so apparently that setfacl -m g::rw does something I don't understand [07:57] hallyn: but "man setfacl" says that it will adjust the unix permissions as close as possible to the specified ACL, so apparently this is resetting the group to "root" [09:04] infinity: time to build fresh precise langpacks [09:04] infinity: I didn't hear from the RT, so I guess I'll build them on a porter box instead of macquarie's chroto? [09:04] chroot [09:04] pitti: Yeah. I'm guessing your chroot didn't get updated yet? [09:04] pitti: If you can fudge it with a porter box this time, that might be nice. [09:04] nope, hardy [09:05] Or we can ask a vanguard if they can get to the ticket today. [09:05] If there was one. [09:05] I guess London's still snoozing. [09:06] I need to copy around the GPG key, launchpadlib token, etc, but no biggie [09:08] pitti: Alright, then let's not block on the ticket, and just hope it gets done before the next raring or precise.3 langpacks. [09:21] infinity: ok, it's running [09:21] pitti: Shiny. [09:22] * pitti hopes that the porter box can talk to launchpad [09:23] pitti: If it can't, we'll escalate the chroot ticket with vigor. [09:26] infinity: .launchpadlib/api.launchpad.net/cache/ is getting data, so I guess it's alright [09:27] \o/ [10:13] I hate writing xorg.conf ;( [10:30] hrw: it's ok, it hates you too. =( [10:30] * xnox hopes to never edit the "safe-fallback" xorg.conf in the installer. [10:31] xnox: I have a feeling that nevermind which gfx card I have foss driver fails [10:32] xnox: radeon + two monitors (one landscape, second portrait) can be configured in first minutes of x11 session only. later one has to display garbage instead [10:38] haha [10:38] radeon with three monitors made me eventually buy an nvidia card [10:50] Is there a way to get a test suite to clean up child processes, no matter what? [10:50] Like if a test that spawns a process crashes, still kill the children. [10:51] infinity: built; I downloaded, built and binary-debdiffed all packages for de and es, looking fine [10:51] infinity: downloading current precise daily to give them a live test in a VM [10:53] Quintasan: Yo. I understand you've been working on packaging maliit - is that right? Where are you up to with that? I'm interested in helping out. :-) === Ursinha-afk is now known as Ursinha [11:09] tedg: Lennart would probably say "use systemd process containers!!!" [11:27] sladen, Looking at cgroups, yes. [11:30] tedg: or you can use PR_SET_CHILD_SUBREAPER to something which will not die (meta-testsuite running process), such that it will be the parent of all run away processes. Which you will be able to kill. [11:30] (which is what user session upstart will do) [11:32] Does anyone here know how I can have a regular event added to the Fridge Calendar (http://fridge.ubuntu.com/calendars/)? === _salem is now known as salem_ [11:34] tedg: Or separate the child processes a bit less vigorously in the first place [11:34] xnox, I'm a bit confused on how to do that... is it something I could have a shell script set? [11:35] (For instance, it should be possible to at least keep them as a member of the same session, I'd have thought) [11:35] The relevant chapter of Stevens APUE should be useful === Amaranthus is now known as Amaranth [11:37] cjwatson, acquired the volume... turns out it's in the library here at Blue Fin :-) [11:38] tedg: well it's a syscall, but somebody did write a package $ sudo apt-get install prctl, but that package seems to lack the subreaper support. So adding subreaper option to that package would be useful, as by default it can spawn shell or execute commands with those process options set. [11:38] tedg: I only need to reach for it about once or twice a year nowadays, but when I do it's invaluable [11:39] and then it all should die gracefully. [11:39] It won't document Linux-specific things; but I'd be surprised if those were necessary here, as opposed to useful [11:40] xnox: PR_SET_CHILD_SUBREAPER is no use here - it was introduced in Linux 3.3, and the buildds run 3.2 [11:40] (i.e. precise) [11:40] So it won't be usable in test suites until at least 2014 [11:42] =( can be used in DEP-8 autopkgtests and / or UTAH based tests at least. [11:42] xnox: tedg's situation is that a runaway test suite is killing LP builders, so we need a solution that works there [11:42] ack. [11:43] tedg: As a belt-and-braces solution, you could get a process list before and after running your test suite, and kill any extra dbus processes that appear [11:43] tedg: It's obviously not perfect but would deal with the immediate problem easily enough [11:43] cjwatson, Yeah, I was thinking using a killall -9 -y dbus-daemon [11:43] Well, I wouldn't do that, because people are allowed to build packages in their ordinary sessions [11:43] cjwatson, It might be easier... though very brute. [11:43] (also, killall is evil, use pkill) [11:44] ++ for pkill [11:44] Well in their sessions the dbus-daemon wouldn't be younger than the test suite. [11:44] (sorry, gut reaction from somebody who used to have to use more SysV-ish systems ...) [11:44] Sure, but just killing all dbus-daemon processes would kill their session dbus too [11:44] Hence needing to take a process list [11:44] Oh, -y - sorry, I misunderstood that option [11:45] It doesn't seem pkill has the same option. [11:45] I guess. I think I'd prefer something more explicit, but as you wish :) [11:47] tedg: Why not just specify a pidfile in the config...? === Ursinha is now known as Ursinha-afk [11:47] Though, I'm also curious why this dbus-daemon, being run with --nofork is being reparented to init at all. [11:47] If I could control enough of the software involved, the way I'd do this would probably be simply to make sure that dbus-daemon remains in the same process group [11:47] Isn't that kind exactly the opposite of what one would expect? [11:48] s/kind/kinda/ [11:48] Then you can kill it with kill(-pgrp) [11:48] Yeah, I do think it's odd that it's hanging out. [11:48] This is all in libdbustest -- patches more than welcome :-) [11:48] So if we used the temp file stuff to make PID files, and then we killed all of them. [11:48] An strace would probably be illuminating (although in this case strace will probably change behaviour - I just mean to see where it's disconnecting itself) [11:54] I'd have to go digging into other packages, but I assume the pidfile way is the general way to go. [11:54] And it doesn't need to be in randomly-named tmpfiles. You control the namespace in your package build. [11:57] infinity, The problem is that we spawn probably 20-30 dbus-daemons [11:58] infinity, Some tests spawn several. [11:59] I guess we could have a unique name for each test... that'd be a bit crazy to manage though. [11:59] tedg: Err, are the tests in paralle or serial? [12:00] tedg: If they're serial, there's no problem with just reusing the same pidfile all over again (or grabbing the pid from --print-pid) [12:00] infinity, Uhm, that's a trick question. They can be run in parallel locally, but the packaging runs them serially. [12:00] infinity, The problem with using the same file is that I'd have to clean up in the shell script, that would have an unknown number of dbus-daemons started. [12:02] After the debs are published can we just kill the builder :-) [12:02] >:( === Ursinha-afk is now known as Ursinha [12:07] tedg: tools/with-session-bus.sh from the telepathy-glib source may be enlightening. [12:08] tedg: And yeah, they use --print-pid=6 and then exec 6> $me-$$.pid [12:08] tedg: But the whole thing may be worth cargo-culting. I doubt there are many testsuites that hit dbus harder than telepathy, and it never has a sad. [12:09] infinity, Well, we're a bit more sophisticated in our dbus testing than they are :-) === Ursinha is now known as Ursinha-afk [12:09] tedg: I disagree. :P [12:09] infinity, But, yes, writing out the PIDs makes sense. [12:12] tedg: And they intentionally fork, so they can get on with their scripts. Which is probably the right thing to do, since --nofork doesn't do anything particularly useful. [12:12] (Sure, it keeps it attached and in the foreground... Right up until the parent dies, and it double-forks to oblivion) === mpt_ is now known as mpt [12:42] meh, I can't get the current precise dailys to work in kvm [13:08] ... nor in virtualbox -- oh for heaven's sake! [13:08] * pitti grumpily downloads the i386 one instead and test on his netbook === Ursinha-afk is now known as Ursinha [13:27] ev: just caught my eye -- we still ship udisks in raring by default due to usb-creator; as gnome disks has had the ability to write images onto devices for a while, and our images are bootable by themselves now, do you think we could drop that? or do you (or someone else) plan to port it to udisks2? === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [13:51] tseliot: I see no point in that nvidia-common upload to precise-proposed. [13:52] infinity: It was just to reassure people who kept on blaming nvidia-common for a bug reported on errors.ubuntu.com [13:53] tseliot: Sure, but if it's just running a test at build time, you could have done the same thing in a PPA. :P [13:54] infinity: oh, sure. Had it been for me I wouldn't have done anything as the code speaks clearly ;) [13:55] tseliot: Right, well, given that it's only ever going to show up in a build log, rather than doing something different on users' machines, I'll just reject it. [13:56] tseliot: Should you ever upload nvidia-common to fix some other bug, feel free to include the shinier test suite too. [13:56] infinity: I will have to backport the linux-headers installation code, so I'll include the test suite in that upload [13:57] tseliot: Sure. When you do, make the bug closure reference in the changelog actually have proper syntax next time. :P [13:59] infinity: oh, it was missing # [13:59] good point [14:00] pitti: ev: I am working on porting to udisks2 now. [14:01] pitti: ev: we can certainly use the "dd image from here to there" method. But doing that we will lose ability to create persistence file, won't we?! [14:02] ogra_: there are a few bugs about not being able to do update-initramfs and/or update-grub when booting from persistent usb. Can we somehow use flash-kernel to update the kernel on the real partition that has the kernel and not the bits inside squashfs? [14:06] xnox: ah, right [14:06] andyrock, if you are here, could you re-approve https://code.launchpad.net/~unity-team/unity/dash-blur-to-linear-sample/+merge/144104 ? === Ursinha is now known as Ursinha-afk [14:07] MCR1, sure [14:07] there was a conflict with trunk that is now fixed [14:07] thx [14:07] MCR1, i now nic just pinged me [14:07] hehe [14:07] ;) [14:07] thanks for testing it ;) [14:08] I just saw the diff ;) [14:09] xnox: cheers! [14:11] ev: not that I enjoy the new UDisks2 API with org.desktop.DBus.ObjectManager a whole load of new interfaces. [14:11] pitti: any good examples of GDBus server python API used in the wild? [14:11] xnox: no, because that doesn't work :( [14:11] pitti: oh? when i manually do 'setfacl -m g::rw' it doesn't change the group for me. (but i'd believe it) [14:12] xnox: mostly due to gnome bug 656325 [14:12] Gnome bug 656325 in gdbus "Make GDBusInterfaceVTable binding friendly" [Normal,Assigned] http://bugzilla.gnome.org/show_bug.cgi?id=656325 [14:12] xnox: so you need to use python-dbus [14:12] xnox: or python3-dbus [14:12] xnox: this was the one that davidz was trying to defend by claiming that it was never intended to be consumed by anything but gdu, right? [14:13] that bug has been on my "assigned" list for far too long; the urgency has greatly been diminished by barry porting python-dbus to python3 [14:13] ev: yeah.... well new API is nice and gives a bucket loads more information, but it's very backwards. And one has to do bottom-up lookups =/ (filesystem->block-device->drive-type) [14:14] xnox: but you know there's gir1.2-udisks-2.0 ? [14:14] xnox: that's the API you ought to use, not the raw D-BUS one [14:14] and do guess work - oh this object has: filesystem & block interface, and it's parent drive has property Optical then I'm guessing it's optical drive. [14:14] xnox: well, you can still use raw D-BUS if you like [14:14] pitti: ha. let me check that. [14:15] xnox: http://cgit.freedesktop.org/udisks/tree/src/tests/integration-test uses it, so if you want to look at that for an example [14:15] ogra_, ok, so my nothing-on-screen-after-nexus-distupgrade ... I can see the session when I change screen backlight level [14:15] well, it does display when I change the value then goes back to blank === Ursinha-afk is now known as Ursinha [14:18] pitti: thanks. looks very similar to DBus api, apart from no need to create connection first. [14:18] xnox: yeah, libudisks and the gir are autogenerated from the D-BUS interface [14:18] xnox: need to run out for a bit, bbl [14:19] =/ why would anyone support multiple ways to access the same crapy API is beyond me [14:20] xnox: try to use libudisks from C, and then do the same with plain gdbus, and you'll know :) [14:20] the difference is a lot smaller in Python of course === francisco is now known as Guest38765 [14:29] Laney: uh oh, I'm supposed to start packaging plugins [14:30] frameworks are done with the exception of tests which fail because they need an X instance, xvfb fails ofc [14:30] Quintasan: did you start from their ppa package? [14:30] pitti: the issue is probably due to the new libc6 version, which broke some stuff. there hasn't been a new upload in a while, because lots of upstream changes broke lots of things, and i've been having to deal with them all across the u1 stack for the past week, including some infrastructure breakaage/downtime [14:30] Laney: More or less, I just took dependencies from there. The rest was done from scratch [14:33] Laney: Do you want to see frameworks pacakging? [14:33] Quintasan: sure [14:33] do you think it's ready to go? [14:33] If missing tests are not a problem then yes [14:33] here I got xvfb tests working but then it's failing later on when trying to link some test with "dummyimplugin" [14:34] 0.94.0? [14:34] yeah [14:34] hmm [14:34] well I say "got", I just xvfb-run make check ... [14:34] oh [14:34] That's how you did it. [14:35] coolbhavi, tumbleweed, mhall119, notgary: ready? :) [14:36] dholbach, yup :-) [14:36] dholbach: I believe I won't be able to translate the packaging manual for this cycle [14:36] Quintasan, do you think you could reach out to the polish loco for some help with translations? [14:36] uni has to eat more stuff than I expected it to. [14:37] dholbach: I'll try, but I can't promise anything [14:37] Quintasan, dzieki! [14:37] dholbach: nie ma za co :) [14:37] Laney: I'll just testbuild it before I sent you not working stuff or something :P [14:37] ok [14:38] Laney: mikhas is at #kubuntu-devel so if you have any particular thing to ask about maliit you can ping him there, or I can ask him to get in here [14:40] ah, I just had to make -C tests and it builds those libraries [14:40] Quintasan: here would be good so I don't have to join another channel :P [14:41] Laney: http://people.ubuntu.com/~quintasan/uploads/maliit-framework_0.94.0-0ubuntu1.debian.tar.gz [14:41] Here is what I got [14:41] pitti: looks like all our necessary fix branches have landed now in our trunk, and our nightlies PPA has built fine, so i'll be able to upload the new version today [14:42] Quintasan: thanks; I'll combine it up with what I have [14:42] Laney: I don't think I have symbols file there but they (i386, amd64, arm) are pending till I get my ARM box running. [14:42] Laney: I'd appreciate it if you left the uploading magic to me since we have to get it along with Plasma Active 3 [14:43] * Quintasan looks at plugins [14:43] Quintasan: Right, I don't know anything about that [14:43] how does that impact uploading to Debian? [14:43] Hmm. [14:43] Oh wait [14:43] Laney: You think you can get it to Debian? [14:44] my key's a bit rusty but it probably still fits the lock ;-) [14:44] That would be like...great. [14:44] anyway I'll get back to you before doing that [14:44] Sure. [14:45] I'll be taking a look at plugins then [14:45] neat [14:46] cyphermox: hi, I was told that you worked on the drivers manager code for software-properties-gtk. Can you have a look at my code, please? https://code.launchpad.net/~albertomilone/software-properties/linux-headers/+merge/145386 [14:46] dholbach: not my turn yet [14:47] mhall119, not immediately, but today, right? :) [14:47] https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 1 starting in 13 minutes in #ubuntu-classroom [14:47] Laney: I think framework still needs symbols file to be generated, got arm box or something to do that or want me to take care of that? [14:48] dholbach: today yes, not yesteray :) [14:48] :-) [14:48] * mhall119 needs much more coffee before he'll be ready [14:49] you should have one or the other minute :) [14:49]