=== alexlist` is now known as alexlist === micahg_ is now known as micahg === Logan_ is now known as Guest50062 === Logan__ is now known as Logan_ === chuck_ is now known as zul === thegatta_ is now known as thegattaca === wgrant_ is now known as wgrant === SpamapS_ is now known as SpamapS [04:59] Good morning [05:00] xnox: I'll look at the xdg runtime dir bug ASAP, thanks [05:00] slangasek: looking at binutils [05:02] I didn't notice anything weird after upgrading udev yesterday (and I did it a lot of times), hmm [05:12] slangasek: binutils> ah, same problem as with libc; an absent "Depends:" field means "Depends: @" which means "all binaries from this source [05:12] slangasek: but adt-run parses debian/control and then tries to install binutils-hppa64 [05:12] slangasek: I'll upload a fix [05:33] meh, I just got the new qemu, and it seems to be totally broken for me now [05:34] key/mouse grabbing doesn't work any more, I cannot start anything from the dash nor press alt+f2 (due to missing screen grab), and when I change the resolution it crashes [05:36] and with default vga it's losing my mouse cursor *sigh* [05:55] xnox: followed up to the bug with some questions which might help with debugging === enrico__ is now known as enrico [06:29] good morning === Guest25862 is now known as Lutin [07:13] Hey, I am trying to package a little script but get complie errors when I try to debuild [07:13] libwnck/libwnck.h not found [07:14] I have got it in the cmakelist though set(DEPS_PACKAGES glib-2.0 granite libwnck-3.0 ) [07:15] have you also the -dev package for it installed? [07:15] yes, it compiles fine when I do it manually [07:15] valac --pkg libwnck-3.0 -X -DWNCK_I_KNOW_THIS_IS_UNSTABLE showdesktop.vala [07:15] with that [07:18] http://pastebin.com/E3EbQp3k [07:19] are you building with pbuilder/schroot or similar? then you also need to have the package listed in Build-Depends so it get installed for the build [07:21] Also in thereIt's also in there [07:21] Build-Depends: cmake (>= 2.8), debhelper (>= 8.0.0), valac-0.16 | valac (>= 0.16), libgranite-dev, libwnck-3-dev, [07:30] Versable: looking at your pastebin it's not the valac call failing but the following gcc call, there seems to be a -I/usr/include/libwnck-3.0 missing [07:31] I have a funny problem with (I believe) resolvconf - etc/resolv.conf is a link to /run/resolvconf/resolv.conf - my wifi seems to have 192.168.1.1 set as its primary DNS, but resolv.conf says it's 127.0.1.1 - and I can't get it to change it (and don't want to edit resolv.conf manually) - did anyone else ever run into this? [07:32] Where/how do I define it, my cmakelist.txt: http://pastebin.com/q9r8PSUK [07:38] Versable: I'm not very familiar with cmake but try to add "libwnck-3.0" to DEPS_PKG (those get passed to pkg-config and I hope cmake passes all those CFLAGS in ${DEPS_CFLAGS}) [07:40] geser: That almost worked, it's giving me "#error "libwnck should only be used if you understand that it's subject to frequent change, and is not supported as a fixed API/ABI or as part of the platform" [07:41] geser: I think I have to pass -X -DWNCK_I_KNOW_THIS_IS_UNSTABLE to gcc too === thegodfather is now known as fabbione [07:43] geser: where would i define global gcc compiler options/arguments === mthaddon` is now known as mthaddon [07:47] dholbach, hey, /etc/resolv.conf isn't a symlink for me [07:47] but I didn't update/restart yet this morning [07:47] this machine is still on raring [07:48] hum... for some reason it wasn't auto-updated for me in the past and I think in some manpage I read that it was supposed to be (or can be) a symlink - either way it's not updated [07:49] seb128: oh, you don't have resolvconf installed? [07:49] pitti, no, I don't [07:49] or rather /run/resolvconf/resolv.conf was updated when I reconnected to my wifi, but it still has 127.0.1.1 instead of 192.168.1.1 as the nameserver [07:49] dholbach, seems like your config is normal then, not mine ... not sure why you have a wrong DNS in there though [07:50] did that start recently? [07:50] Task: minimal [07:50] seb128, in the last few weeks I noticed problems - at the sprint too [07:50] dholbach, it might be that the dns info is sent by the dhcp, are you on a new network? [07:50] seb128, no, my home network [07:50] seb128: missing ubuntu-minimal then? [07:50] and I rebooted the machine last night [07:51] pitti, indeed, that install is over 3 years, I probably got it removed at some point ... installing, thenks ;-) [07:51] Versable: try changing the add_definitions line to : add_definitions(${DEPS_CFLAGS} -DWNCK_I_KNOW_THIS_IS_UNSTABLE) [07:51] pitti, do you have any idea about how resolvconf works otherwise? dholbach gets a wrong DNS info in there [07:52] roughly [07:52] in the past I would have just edited resolv.conf manually and put a nameserver I know in there, but I figured it's be good if it just worked and took the information from DHCP :)( [07:53] so, NM calls dhclient, dhclient calls some script when it's done [07:53] geser: Awesome, that did it, you are my hero of the day :D [07:53] and /etc/resolvconf/update.d/* [07:54] /etc/resolvconf/update.d/libc writes the new nameserver to /run/resolvconf/resolv.conf [07:54] pitti, /run/resolvconf/resolv.conf seems to have been updated when I reconnected to the wifi [07:54] or rather, to /run/resolvconf/interface/ first, and update-resolvconf then builds /run/resolvconf/resolv.conf [07:54] dholbach: ah, so /run/resolvconf/resolv.conf is fine? [07:54] no, it has the wrong dns [07:54] dholbach: /etc/resolv.conf -> ../run/resolvconf/resolv.conf [07:54] pitti, yes [07:54] dholbach: do you have that? [07:54] ah, where's update-resolvconf from? [07:55] dholbach, forums suggests that 127.0.1.1 is dnsmasq [07:55] dholbach: sorry, resolvconf -u [07:55] dholbach, do you have that installed? [07:55] seb128, dnsmasq is not installed [07:55] k, not that then :p [07:55] dholbach: you can check /var/log/syslog for the NetworkMangaer log which address dhclient got from your router [07:56] dholbach: dnsmasq-base [07:56] Jun 5 09:22:57 daydream NetworkManager[877]: nameserver '192.168.1.1' [07:56] and that's required by NM, you ought to have it [07:57] hmm [07:57] dholbach: so what's actually wrong? [07:57] /etc/resolv.conf is supposed to only have 127.0.1.1 [07:57] ahhhh ok [07:57] dholbach: so your computer cannot resolve DNS names? [07:57] i. e. what is the actual problem? [07:57] dnsmasq isn't working? [07:58] I thought it was supposed to be what dhcp told it to be [07:58] a red herring then - it might be some other networking problems [07:58] I think NM moved to dnsmasq to better support things like tethering (but I don't know details -> cyphermox) [07:59] ok [07:59] dholbach, is your system failing to resolv names to ips? [08:00] strange, I just did a "wget http://reqorts.qa.ubuntu.com/reports/sponsoring/" which worked fine, but loading the page in firefox seems stuck at the "looking up ...." stage [08:01] it works fine in chromium [08:01] sorry for all the confusion [08:02] dholbach, ok, that's when you go find chrisccoulson ;-) [08:02] thanks everyone [08:02] dholbach, yw ;-) === ivoks_ is now known as ivoks [08:04] thanks pitti as well [08:04] kein Problem [08:04] and I learned a few more new things now - great :) === slomo_ is now known as slomo [08:11] my ears are burning [08:11] firefox is nothing to do with me now ;) [08:37] xnox: FTR, I tried to open extra sessions after the upgrade, and none of them killed my runtime dir === rbasak_ is now known as rbasak [08:39] pitti: yeah, tested same quickly here. I'm not sure anymore what else I had going on at the time. [08:40] * pitti reads the user_stop() code which calls user_remove_runtime_path() [08:40] but that would kill your whole session, cgroup etc, too [08:40] and ther are no other relevant unlinks/rmdir/rm_rf [08:41] (and even then, logind isn't even supposed to restart during dist-upgrade, I disabled that as the cgroup layout changed in 204) [08:42] xnox: so what could happen: you dist-upgrade, then you or something kills systemd-logind, then you start some new session, the new logind gets spawned [08:42] and that doesn't have any sessions (due to the changed cgroup layout); but then I still don't see why it should call user_stop() as it doesn't have any sessions [08:42] but perhaps something along that line [08:43] xnox: perhaps that upgrade to 204 should just trigger a reboot notification? [08:43] bdmurray, slangasek: I restored the "auto-launch" key in the update-notifier schemas (just there, not the feature in the code), it's being used by update-manager and it was aborting on start with the new update-notifier (gsettings abort on broken schemas/missing keys) [08:43] bdmurray, slangasek: that's a FYI [08:43] bdmurray, slangasek: update-manager should probably be taught about not using that key if it's deprecated [08:44] pitti: That seems reasonable. Given that we only have people who reboot when asked, and otherwise keep their sessions suspended. [08:45] xnox: ok, doing that then; do you think you can squeeze out anything else from this bug? [08:46] pitti: don't think so. [08:48] xnox: ok, doing that then; thanks! [08:58] tkamppeter_: It would be very nice to have you comment on http://bugs.debian.org/711169 as I'm really at loss in all that change. [08:58] Debian bug 711169 in cups-daemon "cups-daemon: ipp printer browsing support removed" [Normal,Open] [09:02] xnox: hm, I called /usr/share/update-notifier/notify-reboot-required, and /var/run/reboot-required is there now, but I don't get an actual reboot notification [09:03] seb128: ^ do you know whether that moved from update-notifier to the indicator, and might not actually work? [09:03] pitti, update-manager is supposed to have a reboot required banner [09:04] oh, we don't make the session indicator red for that any more? ISTR that this was the case [09:04] pitti, let me check for the indicator, I'm not sure if they didn't drop the feature [09:04] do we want new git in saucy? (bug 1187662) [09:04] bug 1187662 in git (Ubuntu) "Sync git 1:1.8.3-1 (main) from Debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/1187662 [09:05] pitti, sorry to bother you [09:05] Has there been any movement internally to bring ubiquity up to parity with manual partitioning features lost by discontinutation of alternate cds? [09:05] As of Ubiquity 2.14.6 (raring release) it is still not possible to manually create/configure lvm within an encrypted physical volume === doko_ is now known as doko [09:05] mitya57: autosync would pick it up anywya. [09:05] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1187660 [09:05] Launchpad bug 43453 in ubiquity (Ubuntu) "duplicate for #1187660 manual ("something else") live cd partitioner doesn't understand lvm properly" [Medium,Triaged] [09:05] infinity: not from experimental [09:05] Oh. [09:05] Right. [09:05] Just saw that. [09:06] Then yes, I want a new git, and I'm syncing it. :P [09:06] anon^_^: hm, I'm not working on ubiquity; I haven't heard of plans to extend that, maybe xnox or stgraber know [09:07] anon^_^: there are wireframes done, and I did start implementing it, but it wasn't finished and it isn't a priority to complete at the moment. === tkamppeter_ is now known as tkamppeter [09:07] seb128: ah right, u-m tells me to reboot; but that doesn't really help for apt-get [09:07] anon^_^: thus I marked your bug as a duplicate of an earlier one. [09:07] xnox any sort of timeline? [09:07] sorry i just noticed, logged out awhile back [09:07] pitti, the indicator is still supposed to turn red afact but better to check with larsu/ted/charles [09:08] pitti, src/dialog.c: return g_file_test("/var/run/reboot-required", G_FILE_TEST_EXISTS); [09:08] -rw-r--r-- 1 root root 42 Jun 5 11:06 /var/run/reboot-required [09:08] yep, definitively [09:08] seb128: err, is that from the indicator? it's hardly a dialog [09:08] pitti, if you pick shutdown, does the dialog tell you that restart is needed? [09:09] no [09:09] it should [09:09] also, why would I pick shutdown [09:09] oh, but we replaced those dialog by unity ones [09:09] OdyX, the only way to replace the removed broadcasting/browsing in CUPS is to use avahi-daemon and cups-browsed and use package dependencies to get the smooth transition for the user. [09:09] well, I would, but it seems xnox doesn't, he always just suspends [09:09] pitti, sorry, logout [09:09] seb128: same thing though; it's the other way around, people wouldn't log out until they see that they need to reboot [09:10] hence the nice "turn indicator red for reboot" [09:10] pitti, to check with larsu/ted/charles, I'm sorry but I'm unsure of the details, I seem to remember that mpt/design told them to drop the red entry but I'm not sure now [09:10] ack [09:10] pitti, well, update-manager tell you to reboot after upgrade [09:10] so users should see it [09:11] I'm not sure the red was all that intuitive, but we need *something* to inform people who aren't using update-manager. [09:11] it even don't let you a choice, they removed the close button from that dialog [09:11] yeah, that's nasty, too [09:11] My motd doesn't even seem to be yelling at me about /var/run/reboot-required anymore. [09:11] Hrm. [09:11] infinity, if people are smart enough to not use our provided tools they should be smart enough to know when to reboot :op [09:12] Maybe. [09:12] I like the nag. I forget after a while. [09:12] Like, I'll upgrade and know I needed to reboot, but then work for another two days and forget. :P [09:12] yeah, that's why I liked the red indicator [09:14] The following packages have been kept back: [09:14] gcc-4.8-base:i386 libgcc1:i386 libstdc++6:i386 [09:14] * infinity looks sideways at apt. [09:19] infinity, pitti, xnox: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.10/revision/275 [09:19] ok, found it back [09:19] *sniff* [09:20] Sadness. [09:20] slangasek: yay, binutils succeeds now \o/ [09:20] (the autopkgtest) [09:21] hallyn: Grr. You dropped my qemu change. Again. [09:21] hallyn: Are you merging in a way that ignores the archive? Should I be committing somewhere magical? [09:33] tkamppeter: IPP doesn't work anymore ? Also, could you comment on the bug, it would be very helpful. === ckpringle_ is now known as ckpringle [09:48] mardy: hey, subscribed you to a couple of uoa/eds bugs that I found if you've time to look at them some time :-) === psivaa_ is now known as psivaa [09:56] pitti, slangasek, uuuh ... with bug 1187616 you need to be super duper careful, we already load all firmware in android, some devices really dont like if it gets loaded twice [09:56] bug 1187616 in systemd (Ubuntu) "udev firmware handler needs to support multiple firmware sources for Ubuntu Touch" [Undecided,Fix committed] https://launchpad.net/bugs/1187616 [09:57] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [09:57] ogra: do drivers issue a firmware uevent if they already have the fw loaded? [09:58] ogra: if this gets in the way, it's fine to revert of course; it just sounded to me like something which is needed [09:58] (preferably you leave it to the binary driver to use it's hardcoded path (which means you need to have the right mountpoints) and dont have udev intervene at all here) [09:58] pitti, well, it will help for some drivers, but definitely break some too [09:58] ogra: OK, I leave it to you and slangasek to figure out what needs to happen :) [09:58] ogra: but drivers definitively shouldn't ask for firmware if they already have it [09:59] normally the android driver has a hardcoded firmware path and probably a fallback ... that is the reason why we need to have the android mountpoints in ubuntu at the right places [10:00] pitti, well, depends, the drivers load their stuff inside an lxc container we probably dont have the info that it is loaded outside of that container [10:01] lxc containers don't have their own drivers/kernels [10:01] preferably we dont want to handle drivers under ubuntu at all if they are alreayd set up in the container ... *but* we want udev to provide the same interfaces in /dev that the container has [10:02] no, but their own userspace that acts completely different from ours [10:02] firmware information isn't in /dev, it's in /sys (and uevents); those should be shared across all containers [10:02] theoretically all deviCes should be handled in the container and our userspace only talks to them through the platform-api sockets and /dev [10:02] ogra: alright; as I said, if you figure out how it ought to be, feel free to upload or poke me to upload [10:03] yeah, i'lll need to talk to steve for sure ... and i guess that needs some deep testing [10:04] i think we ratrher want an option to ignore device initialization and just some rules that mimic the android /dev for us [10:04] ogra: would be interesting to see if there is actually a driver which we need to handle that way [10:05] lxc-android-config already ships a bunch of rules ... [10:22] ev: https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=martin.pitt@ubuntu.com&period=month says "no such user", and https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=pitti&period=month has "no data to display"; is that not the LP user ~pitti, but something else perhaps? [10:22] ev: or not the packages I'm subscribed to in LP? [10:23] * ev looks [10:23] user=pitti is definitely correct, by the way [10:24] ev: well, in the very best case there just are no crash reports in my packages, but I wouldn't trust that yet :) [10:24] no, there should be [10:24] if you take your name out, there are apport crashes in that list [10:24] * pitti tries https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=seb128&period=month [10:24] and I would assume you're at least subscribed to that :) [10:24] bdmurray: ^ thoughts? The API call is definitely returning the empty set: https://errors.ubuntu.com/api/1.0/most-common-problems/?format=json&limit=100&release=Ubuntu%2013.10&user=pitti&period=month [10:24] yes, I'm sub'ed to like two dozen === dmart_ is now known as dmart [10:25] pitti, is that a "pitti haz no bog but seb does"? ;-) [10:25] "An error occurred while trying to load the most common problems" [10:25] seems seb128 is oversubscribed and over-bugged :) [10:26] lol [10:26] works here [10:26] but 13.10 has very few users [10:26] those stats are not very useful [10:26] filed https://bugs.launchpad.net/errors/+bug/1187723 to track it [10:26] Launchpad bug 1187723 in Errors "Martin Pitt's subscribed packages view returns the empty set" [Undecided,Triaged] [10:27] bdmurray: if you don't have time for that one, let me know and I'll have a look [10:28] https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=cjwatson&period=month [10:28] that just has one bug [10:28] presumably wrong, too [10:30] pitti, well, as said the numbers are low, see https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=month [10:30] pitti, entry 16 is down to 4 reports in a month [10:30] yeah, that's right [10:31] that seems buggy low though [10:31] yes, I meant "right, it's too low and looks wrong" [10:34] ev, how long does it take between submit and datas supposed to be listed on e.g https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=day ? [10:34] seb128: it's instantaneous [10:34] well [10:34] if it's Python :) [10:34] for binary crashes that haven't already been retraced, it needs to go through that process first [10:35] and that can take some time - we're having issues at the moment around the Swift backend storage we use for the core dumps [10:35] in that it's not accepting them [10:35] ev, pitti and Laney reported some issues earlier today on evolution-data-server and signon-ui and the report has 0 entry for those components today, is that normal? [10:35] but we're also in the middle of a move to oops.canonical.com, which makes debugging that tricky [10:36] ok [10:36] yes, because e-d-s is a binary and the retracers are having difficulty due to the problem mentioned above [10:36] working to resolve it as quickly as I can [10:36] no worry [10:37] it's not a today problem, but the 13.10 number of reports seem low (that's not new) and I was wondering if that's just low number of users or if there is a bug and we loose datas on the way [10:39] seb128: sure, and thanks for making me aware of it. I suspect it's a combination of the two. We don't get a lot of users this early in the release, but there's also the bug preventing retracing from happening. We're not losing data per-se, as we're just dropping core submissions on the ground. We still have all the metadata for each crash that comes in, and when a matching core file is submitted from a different user and its finally retraced, those [10:39] crashes will be bucketed. === statik_ is now known as statik [10:40] ev, ok, good to know that the datas are not lost, thanks for the status update [10:41] seb128: yeah, it's a big thing of mine that we try as hard as we can to never drop the actual reports or ever remove them from the DB [10:41] we often need to iterate back over them as we learn how to do things better or add new features [10:41] and big gaps would make future calculations of "are we doing better?" look weird [10:42] sure thing though. As always, let me know if anything else is broken [10:43] Laney: thanks! I asked help from the Evolution maintainer, in turn :-) [10:43] :D [10:47] Laney: did you try killing evolution-calendar-factory? [10:47] mardy: for the indicator one? [10:47] (no, but can do) [10:48] Laney: I'd say for both [10:48] ok, let me re-add the account and try [10:48] Laney: I guess they are very strictly related [10:48] yes, I think so === ckpringle_ is now known as ckpringle [10:49] hm, straight after adding it I get told it's not authorised and then "Grant access" takes me to a page with standard Username/Password entries instead of the usual webview [10:51] Laney: weird... you are talking about the Google account? [10:51] yes [10:51] Laney: ah, maybe it's not that weird; I think that for the calendar EDS is using a plain username/password authentication [10:52] so it could be choking on my 2fa then? [10:52] killing the calendar factory made me get the same not authorised thing [10:53] mardy: didn't make it work though [10:53] but I suppose this is more information [10:54] Laney: yes, it looks like the username/password is invalid, or anyway not enough to authenticate [10:54] Laney: is that a 2-factor-auth enabled account? [10:54] yep, both are (canonical and personal) [10:55] well, canonical is 2 factor through Ubuntu SSO; don't know how that interacts with this [10:55] * Laney tries adding that one [10:56] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [10:57] * Laney remembers that he has an old google account without 2fa [10:57] now, what are the details for that? [10:58] Laney: despite 2fa/SSO on the google-account, for e.g. plain access (webdav, ical, smtp, imap, etc) you need "normal bog-standard google password" for canonical accounts or the "static application specific" passwords for personal accounts. [10:58] Laney: if you don't remember it, #is can reset it for you. (there is no web ui to do it) [10:59] I have the Google account password, but giving that on the "plain" page didn't make it succeed [10:59] =( [11:01] the touch images need all android groups in the system on the ubuntu side with fixed GIDs ... currently we create them at build time with a live-build hook script, i'm planning to move all this into a postinst of the lxc-android-config package, does anymone know what happens if a group with a GID i need already exists ? [11:02] mardy: Aha — I added another, non 2fa, account and that seems to work beautifully. [11:03] ogra: If you need fixed GIDs then you must coordinate with the Debian base-passwd maintainer [11:03] ogra: (i.e. me) [11:03] at least email and calendar in evo, and I got loads of spam friend requests on empathy [11:04] ogra: Send mail to base-passwd@packages.debian.org with your requirements and we can talk through them [11:04] cjwatson, i think they are all above 1000, i'm just wondering [11:04] so it seems like the altenate authentication workflow needs more work (even if that's to fail better for now) [11:04] ogra: Please send me mail since it sounds like you're doing bad things and I want to help you do good things instead. :-) [11:04] and i dont have a complete list yet ... only know the wones we use already ... perferably we want them alll though [11:04] cjwatson, well, we dont have much choice ... the GIDs are hardcoded in the kernel [11:05] android is doing bad things here [11:05] but yeah, let me get a full list and i'll mail [11:05] Oh, they're specific fixed GIDs forced on you by external forces [11:05] That's ... not ideal [11:05] yeah [11:05] thats android :) [11:06] and binary daemons might rely on it [11:06] Still, I'd like to have a mail record of what's going on here, even if we can't do anything about it [11:06] right, i'll first discuss that with rsalveti [11:06] in any case i want it in a package postinst instead of having a build script === nigelb_ is now known as nigelb [11:10] ogra: dont do bad things - i told you before :-P [11:10] haha [11:10] not sure why the good ogra is always doing such things [11:10] OdyX`, I have commented on the bug now. [11:11] I don't suppose there's any hope of libhybris doing whizzy GID mapping for us so that we don't have to know about the Android GIDs on the Ubuntu side? [11:11] For that matter, shouldn't this be handled by running the Android binary daemons in a container? Container GIDs don't have to match the host ones [11:12] the issue is that the kernel refuses device access for some bits if the GID doesnt match exactly [11:12] Mm. I thought this was the kind of thing libhybris was supposed to be able to help with. [11:13] i.e. network access is only allowed for GID 3002 3003 3004 [11:13] so if we access devices on the ubuntu side they need to be owned by the right group and the user needs to be part of them [11:13] radio is similar ... [11:14] live-build/ubuntu-touch/hooks/02-add_user_to_groups.chroot has the current list we use [11:16] (but there are a lot more) [11:23] aha [11:23] found the mapping in the android tree [11:23] http://paste.ubuntu.com/5735451/ should be the full list [11:23] seems to be all above 1000 [11:24] The whole thing is based on fundamentally different assumptions about how things are laid out though; e.g. the system user at 1000 [11:24] yeah, well [11:24] dont tell me :) [11:24] I kind of think we're going to get ourselves into trouble if we assume that the only way to address this is to create matching groups on the Ubuntu side [11:24] we cant hack binary daemons ro drivers that are linked against this [11:25] we could change thee kernel, but that wont fix bianry blobs [11:25] *binary [11:25] We could, for example, punt certain kinds of device access behind the scenes through the Android container [11:25] depends if you access stuff directly through a socket or not [11:26] You use the C library to create the socket, so ... [11:26] i.e. ofono attaches to the binary vendor rild via a socket [11:26] which has to be the original one from android [11:26] (linked into /dev from the android /dev) [11:27] might be possible to have a wrapper or some such [11:27] but i dont think anyone even throught about GID remapping yet [11:27] Somebody might have to :) [11:27] definitely ... [11:27] Anyway, if you do create these groups, please create only the minimal set you absolutely need so that any future cleanup is kept to a minimum and there's the lowest probability of clashes [11:28] yeah, indeed [11:28] the above live-build script has the minimal set we need atm [11:29] (only 10 groups with fixed GID in there atm) [11:30] You'll have to just use 'getent group GROUP_NAME >/dev/null || addgroup --gid NEW_GID GROUP_NAME', I think, or similar, and if it fails there's nothing you can do [11:30] You can't even use --system since these aren't in the system range [11:30] yeah [11:31] Do please use addgroup rather than the low-level groupadd stuff you're doing right now though [11:31] And OMG what is all that madness adding global static groups [11:31] Most of that script desperately needs to be deleted [11:32] will do, i need to discuss that with sergiusens and rsalveti anyway before i do anything ... looking at the script it seems to not care about GIDs at all if for example a group already exists [11:32] * doko watches cjwatson's blood pressure going up ... [11:32] Heh === bjsnider_ is now known as bjsnider [11:32] * mlankhorst puts cjwatson in AID_UNUSED1 [11:33] * ogra points out that he is just the messenger ... not my script [11:33] i just want to clean that up and not have it in the build scripts [11:33] Sure, I know, but you can be a messenger in the other direction too :P [11:33] thats what i plan [11:33] There might be an argument for it creating admin (but it MUST use 'addgroup --system' to do it, if it does); there is absolutely no justification for it creating any of the groups listed in /usr/share/base-passwd/group.master [11:33] Especially not in that invalid way [11:33] i consider sanitizing this part of the container flip [11:34] which as i said above, has no real planning at all yet [11:34] And it should use adduser to add the user to that set of groups, not usermod [11:34] yeah [11:34] * cjwatson attempts to haul this up to saner levels of the stack [11:35] let me discuss with our android heads first, before we take any action ... [11:36] i think *if* we have such s script it definitely belongs into the android container package though ... not in the build scripts (i.e. on x86 you most likely would want that stuff at all) [11:36] *wouldn't === jelmer_ is now known as jelmer === d1b_ is now known as d1b === shadeslayer_ is now known as shadeslayer [11:59] infinity: I woulda held off but there was a cve fix in there too. As for the sources, I keep them at github.com/hallyn/qemu, and I rebase against debian-unstable from git://anonscm.debian.org/pkg-qemu/qemu.git [11:59] infinity: if you prefer i can ping you before a next update - though i'm hoping i'm done for awhile [12:02] infinity: i swear i checked for later updates! but i guess i did that before rebasing - sorry [12:03] won't happen again [12:06] (pushing your change to github for good measure0 [12:06] bug 1187750 [12:06] bug 1187750 in livecd-rootfs (Ubuntu) "system group creation for android container device access needs to move out of the build scripts" [Undecided,New] https://launchpad.net/bugs/1187750 [12:06] cjwatson, ^^^ [12:07] ogra: Independent of that, can I just go ahead and delete the spurious attempts to create global static groups (the ones base-passwd ships on all systems)? [12:07] cjwatson, definitely [12:08] Whoa, what the heck is that stuff with the audio gid :-( [12:08] That's going to break as soon as base-passwd is upgraded [12:08] yeah [12:09] thats why the touch images are not officially supporting apt based upgrades i guess :) [12:10] Well it's just plain wrong [12:10] If you need a fixed gid for audio handling that doesn't match the one in base-passwd then it must be called something else [12:11] android_audio then ... though that will obsolete the normal audio group [12:12] Better to obsolete it than to screw it over [12:12] indeed [12:19] asac, you might want to monitor the ablve bug too probably [12:19] *above [12:19] * ogra ponders to file the same thing about the environemnt setup ... live-build currently overwrites /etc/environment and fills it with a ton of stuff [12:21] (in live-build/ubuntu-touch/hooks/48-setup-env.chroot ) [12:23] mm, that seems like it should be set by a session script or something [12:23] SHLVL=1 ??? [12:23] Did somebody run env and copy and paste, or something? [12:24] could be [12:24] cjwatson: ogra I already removed some gid checking which you never saw, like access to surfaceflinger or sensors [12:24] i have no idea how these scripts were developed initially [12:24] it predates my involvement [12:25] for audio, I'm guessing most of it will go away once jim finishes up his native ubuntu audio integration [12:25] sergiusens, well, the question is what do we really need [12:25] rild is a pain though [12:25] i assume for everything that talks directly to an android socket like rild we wont get around having the groups [12:25] yeah [12:26] but for all other stuff we might be able to find a better solution [12:26] depends, as I say, what interface android is using to find out the group id of its peer, and whether that can be fooled [12:26] or even have a wrapper on the ubuntu side that does some re-mapping or so [12:27] cjwatson, well, android obviously uses its header files ... but i know that the kernel also uses some of this [12:27] the prob are really the binary bits we dont have contol over ... though only if we talk to them directly [12:27] cjwatson: ogra I'll take this one and start on Monday if rsalveti isn't eager to (I'm off tomorrow and the day after) [12:28] sergiusens, whats your solution ? [12:28] ogra: let me look at it first and then propose something ;-) [12:28] is anything else but ofono talking directly to rild ? we might be able to have a wrapper in there that does the remapping [12:29] ogra: so gps creates an IPC socket on manta on /data [12:29] the binary blob that is [12:30] so let me consolidate all the cases we have and see if I can factor something common for all === wedgwood_away is now known as wedgwood [12:33] hallyn: S'all good, was just mildly annoyed when I saw component-mismatches explode again. [12:35]