[04:59] <pitti> Good morning
[05:00] <pitti> xnox: I'll look at the xdg runtime dir bug ASAP, thanks
[05:00] <pitti> slangasek: looking at binutils
[05:02] <pitti> I didn't notice anything weird after upgrading udev yesterday (and I did it a lot of times), hmm
[05:12] <pitti> slangasek: binutils> ah, same problem as with libc; an absent "Depends:" field means "Depends: @" which means "all binaries from this source
[05:12] <pitti> slangasek: but adt-run parses debian/control and then tries to install binutils-hppa64
[05:12] <pitti> slangasek: I'll upload a fix
[05:33] <pitti> meh,  I just got the new qemu, and it seems to be totally broken for me now
[05:34] <pitti> 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] <pitti> and with default vga it's losing my mouse cursor *sigh*
[05:55] <pitti> xnox: followed up to the bug with some questions which might help with debugging
[06:29] <dholbach> good morning
[07:13] <Versable> Hey, I am trying to package a little script but get complie errors when I try to debuild
[07:13] <Versable> libwnck/libwnck.h not found
[07:14] <Versable> I have got it in the cmakelist though set(DEPS_PACKAGES     glib-2.0     granite     libwnck-3.0 )
[07:15] <geser> have you also the -dev package for it installed?
[07:15] <Versable> yes, it compiles fine when I do it manually
[07:15] <Versable> valac --pkg libwnck-3.0 -X -DWNCK_I_KNOW_THIS_IS_UNSTABLE showdesktop.vala 
[07:15] <Versable> with that
[07:18] <Versable> http://pastebin.com/E3EbQp3k
[07:19] <geser> 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] <Versable> Also in thereIt's also in there
[07:21] <Versable> Build-Depends: cmake (>= 2.8),                debhelper (>= 8.0.0),                valac-0.16 | valac (>= 0.16),                libgranite-dev,                libwnck-3-dev,
[07:30] <geser> 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] <dholbach> 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] <Versable> Where/how do I define it, my cmakelist.txt: http://pastebin.com/q9r8PSUK
[07:38] <geser> 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] <Versable> 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] <Versable> geser: I think I have to pass  -X -DWNCK_I_KNOW_THIS_IS_UNSTABLE to gcc too
[07:43] <Versable> geser: where would i define global gcc compiler options/arguments
[07:47] <seb128> dholbach, hey, /etc/resolv.conf isn't a symlink for me
[07:47] <seb128> but I didn't update/restart yet this morning
[07:47] <dholbach> this machine is still on raring
[07:48] <dholbach> 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] <pitti> seb128: oh, you don't have resolvconf installed?
[07:49] <seb128> pitti, no, I don't
[07:49] <dholbach> 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] <seb128> dholbach, seems like your config is normal then, not mine ... not sure why you have a wrong DNS in there though
[07:50] <seb128> did that start recently?
[07:50] <pitti> Task: minimal
[07:50] <dholbach> seb128, in the last few weeks I noticed problems - at the sprint too
[07:50] <seb128> dholbach, it might be that the dns info is sent by the dhcp, are you on a new network?
[07:50] <dholbach> seb128, no, my home network
[07:50] <pitti> seb128: missing ubuntu-minimal then?
[07:50] <dholbach> and I rebooted the machine last night
[07:51] <seb128> pitti, indeed, that install is over 3 years, I probably got it removed at some point ... installing, thenks ;-)
[07:51] <geser> Versable: try changing the add_definitions line to : add_definitions(${DEPS_CFLAGS} -DWNCK_I_KNOW_THIS_IS_UNSTABLE)
[07:51] <seb128> pitti, do you have any idea about how resolvconf works otherwise? dholbach gets a wrong DNS info in there
[07:52] <pitti> roughly
[07:52] <dholbach> 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] <pitti> so, NM calls dhclient, dhclient calls some script when it's done
[07:53] <Versable> geser: Awesome, that did it, you are my hero of the day :D
[07:53] <pitti> and /etc/resolvconf/update.d/*
[07:54] <pitti> /etc/resolvconf/update.d/libc writes the new nameserver to /run/resolvconf/resolv.conf
[07:54] <dholbach> pitti, /run/resolvconf/resolv.conf seems to have been updated when I reconnected to the wifi
[07:54] <pitti> or rather, to /run/resolvconf/interface/ first, and update-resolvconf then builds /run/resolvconf/resolv.conf
[07:54] <pitti> dholbach: ah, so /run/resolvconf/resolv.conf is fine?
[07:54] <dholbach> no, it has the wrong dns
[07:54] <pitti> dholbach: /etc/resolv.conf -> ../run/resolvconf/resolv.conf
[07:54] <dholbach> pitti, yes
[07:54] <pitti> dholbach: do you have that?
[07:54] <dholbach> ah, where's update-resolvconf from?
[07:55] <seb128> dholbach, forums suggests that 127.0.1.1 is dnsmasq
[07:55] <pitti> dholbach: sorry, resolvconf -u
[07:55] <seb128> dholbach, do you have that installed?
[07:55] <dholbach> seb128, dnsmasq is not installed
[07:55] <seb128> k, not that then :p
[07:55] <pitti> dholbach: you can check /var/log/syslog for the NetworkMangaer log which address dhclient got from your router
[07:56] <pitti> dholbach: dnsmasq-base
[07:56] <dholbach> Jun  5 09:22:57 daydream NetworkManager[877]: <info>   nameserver '192.168.1.1'
[07:56] <pitti> and that's required by NM, you ought to have it
[07:57] <pitti> hmm
[07:57] <pitti> dholbach: so what's actually wrong?
[07:57] <pitti> /etc/resolv.conf is supposed to only have 127.0.1.1
[07:57] <dholbach> ahhhh ok
[07:57] <pitti> dholbach: so your computer cannot resolve DNS names?
[07:57] <pitti> i. e. what is the actual problem?
[07:57] <pitti> dnsmasq isn't working?
[07:58] <dholbach> I thought it was supposed to be what dhcp told it to be
[07:58] <dholbach> a red herring then - it might be some other networking problems
[07:58] <pitti> I think NM moved to dnsmasq to better support things like tethering (but I don't know details -> cyphermox)
[07:59] <dholbach> ok
[07:59] <seb128> dholbach, is your system failing to resolv names to ips?
[08:00] <dholbach> 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] <dholbach> it works fine in chromium
[08:01] <dholbach> sorry for all the confusion
[08:02] <seb128> dholbach, ok, that's when you go find chrisccoulson ;-)
[08:02] <dholbach> thanks everyone
[08:02] <seb128> dholbach, yw ;-)
[08:04] <dholbach> thanks pitti as well
[08:04] <pitti> kein Problem
[08:04] <dholbach> and I learned a few more new things now - great :)
[08:11] <chrisccoulson> my ears are burning
[08:11] <chrisccoulson> firefox is nothing to do with me now ;)
[08:37] <pitti> xnox: FTR, I tried to open extra sessions after the upgrade, and none of them killed my runtime dir
[08:39] <xnox> 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] <pitti> but that would kill your whole session, cgroup etc, too
[08:40] <pitti> and ther are no other relevant unlinks/rmdir/rm_rf
[08:41] <pitti> (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] <pitti> 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] <pitti> 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] <pitti> but perhaps something along that line
[08:43] <pitti> xnox: perhaps that upgrade to 204 should just trigger a reboot notification?
[08:43] <seb128> 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] <seb128> bdmurray, slangasek: that's a FYI
[08:43] <seb128> bdmurray, slangasek: update-manager should probably be taught about not using that key if it's deprecated
[08:44] <xnox> pitti: That seems reasonable. Given that we only have people who reboot when asked, and otherwise keep their sessions suspended.
[08:45] <pitti> xnox: ok, doing that then; do you think you can squeeze out anything else from this bug?
[08:46] <xnox> pitti: don't think so.
[08:48] <pitti> xnox: ok, doing that then; thanks!
[08:58] <OdyX`> 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.
[09:02] <pitti> 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] <pitti> seb128: ^ do you know whether that moved from update-notifier to the indicator, and might not actually work?
[09:03] <seb128> pitti, update-manager is supposed to have a reboot required banner
[09:04] <pitti> oh, we don't make the session indicator red for that any more? ISTR that this was the case
[09:04] <seb128> pitti, let me check for the indicator, I'm not sure if they didn't drop the feature
[09:04] <mitya57> do we want new git in saucy? (bug 1187662)
[09:05] <anon^_^> pitti, sorry to bother you
[09:05] <anon^_^> Has there been any movement internally to bring ubiquity up to parity with manual partitioning features lost by discontinutation of alternate cds?
[09:05] <anon^_^> As of Ubiquity 2.14.6 (raring release) it is still not possible to manually create/configure lvm within an encrypted physical volume
[09:05] <infinity> mitya57: autosync would pick it up anywya.
[09:05] <anon^_^> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1187660
[09:05] <pitti> infinity: not from experimental
[09:05] <infinity> Oh.
[09:05] <infinity> Right.
[09:05] <infinity> Just saw that.
[09:06] <infinity> Then yes, I want a new git, and I'm syncing it. :P
[09:06] <pitti> anon^_^: hm, I'm not working on ubiquity; I haven't heard of plans to extend that, maybe xnox or stgraber know
[09:07] <xnox> 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.
[09:07] <pitti> seb128: ah right, u-m tells me to reboot; but that doesn't really help for apt-get
[09:07] <xnox> anon^_^: thus I marked your bug as a duplicate of an earlier one.
[09:07] <anon^_^> xnox any sort of timeline?
[09:07] <anon^_^> sorry i just noticed, logged out awhile back
[09:07] <seb128> pitti, the indicator is still supposed to turn red afact but better to check with larsu/ted/charles
[09:08] <seb128> pitti, src/dialog.c:	return g_file_test("/var/run/reboot-required", G_FILE_TEST_EXISTS);
[09:08] <pitti> -rw-r--r-- 1 root root 42 Jun  5 11:06 /var/run/reboot-required
[09:08] <pitti> yep, definitively
[09:08] <pitti> seb128: err, is that from the indicator? it's hardly a dialog
[09:08] <seb128> pitti, if you pick shutdown, does the dialog tell you that restart is needed?
[09:09] <pitti> no
[09:09] <seb128> it should
[09:09] <pitti> also, why would I pick shutdown
[09:09] <seb128> oh, but we replaced those dialog by unity ones
[09:09] <tkamppeter> 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] <pitti> well, I would, but it seems xnox doesn't, he always just suspends
[09:09] <seb128> pitti, sorry, logout
[09:09] <pitti> 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] <pitti> hence the nice "turn indicator red for reboot"
[09:10] <seb128> 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] <pitti> ack
[09:10] <seb128> pitti, well, update-manager tell you to reboot after upgrade
[09:10] <seb128> so users should see it
[09:11] <infinity> 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] <seb128> it even don't let you a choice, they removed the close button from that dialog
[09:11] <pitti> yeah, that's nasty, too
[09:11] <infinity> My motd doesn't even seem to be yelling at me about /var/run/reboot-required anymore.
[09:11] <infinity> Hrm.
[09:11] <seb128> 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] <infinity> Maybe.
[09:12] <infinity> I like the nag.  I forget after a while.
[09:12] <infinity> Like, I'll upgrade and know I needed to reboot, but then work for another two days and forget. :P
[09:12] <pitti> yeah, that's why I liked the red indicator
[09:14] <infinity> The following packages have been kept back:
[09:14] <infinity>   gcc-4.8-base:i386 libgcc1:i386 libstdc++6:i386
[09:14]  * infinity looks sideways at apt.
[09:19] <seb128> infinity, pitti, xnox: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.10/revision/275
[09:19] <seb128> ok, found it back
[09:19] <pitti> *sniff*
[09:20] <infinity> Sadness.
[09:20] <pitti> slangasek: yay, binutils succeeds now \o/
[09:20] <pitti> (the autopkgtest)
[09:21] <infinity> hallyn: Grr.  You dropped my qemu change.  Again.
[09:21] <infinity> hallyn: Are you merging in a way that ignores the archive?  Should I be committing somewhere magical?
[09:33] <OdyX`> tkamppeter: IPP doesn't work anymore ? Also, could you comment on the bug, it would be very helpful.
[09:48] <Laney> mardy: hey, subscribed you to a couple of uoa/eds bugs that I found if you've time to look at them some time :-)
[09:56] <ogra> 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:57] <dholbach> @pilot in
[09:57] <pitti> ogra: do drivers issue a firmware uevent if they already have the fw loaded?
[09:58] <pitti> 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] <ogra> (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] <ogra> pitti, well, it will help for some drivers, but definitely break some too
[09:58] <pitti> ogra: OK, I leave it to you and slangasek to figure out what needs to happen :)
[09:58] <pitti> ogra: but drivers definitively shouldn't ask for firmware if they already have it
[09:59] <ogra> 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] <ogra> 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] <pitti> lxc containers don't have their own drivers/kernels
[10:01] <ogra> 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] <ogra> no, but their own userspace that acts completely different from ours
[10:02] <pitti> firmware information isn't in /dev, it's in /sys (and uevents); those should be shared across all containers
[10:02] <ogra> 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] <pitti> 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] <ogra> yeah, i'lll need to talk to steve for sure ... and i guess that needs some deep testing
[10:04] <ogra> i think we ratrher want an option to ignore device initialization and just some rules that mimic the android /dev for us
[10:04] <pitti> ogra: would be interesting to see if there is actually a driver which we need to handle that way
[10:05] <ogra> lxc-android-config already ships a bunch of rules ...
[10:22] <pitti> 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] <pitti> ev: or not the packages I'm subscribed to in LP?
[10:23]  * ev looks
[10:23] <ev> user=pitti is definitely correct, by the way
[10:24] <pitti> 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] <ev> no, there should be
[10:24] <ev> 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] <ev> and I would assume you're at least subscribed to that :)
[10:24] <ev> 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] <pitti> yes, I'm sub'ed to like two dozen
[10:25] <seb128> pitti, is that a "pitti haz no bog but seb does"? ;-)
[10:25] <pitti> "An error occurred while trying to load the most common problems"
[10:25] <pitti> seems seb128 is oversubscribed and over-bugged :)
[10:26] <seb128> lol
[10:26] <seb128> works here
[10:26] <seb128> but 13.10 has very few users
[10:26] <seb128> those stats are not very useful
[10:26] <ev> filed https://bugs.launchpad.net/errors/+bug/1187723 to track it
[10:27] <ev> bdmurray: if you don't have time for that one, let me know and I'll have a look
[10:28] <pitti> https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=cjwatson&period=month
[10:28] <pitti> that just has one bug
[10:28] <pitti> presumably wrong, too
[10:30] <seb128> pitti, well, as said the numbers are low, see https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=month
[10:30] <seb128> pitti, entry 16 is down to 4 reports in a month
[10:30] <pitti> yeah, that's right
[10:31] <seb128> that seems buggy low though
[10:31] <pitti> yes, I meant "right, it's too low and looks wrong"
[10:34] <seb128> 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] <ev> seb128: it's instantaneous
[10:34] <ev> well
[10:34] <ev> if it's Python :)
[10:34] <ev> for binary crashes that haven't already been retraced, it needs to go through that process first
[10:35] <ev> 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] <ev> in that it's not accepting them
[10:35] <seb128> 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] <ev> but we're also in the middle of a move to oops.canonical.com, which makes debugging that tricky
[10:36] <seb128> ok
[10:36] <ev> yes, because e-d-s is a binary and the retracers are having difficulty due to the problem mentioned above
[10:36] <ev> working to resolve it as quickly as I can
[10:36] <seb128> no worry
[10:37] <seb128> 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] <ev> 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] <ev>  crashes will be bucketed.
[10:40] <seb128> ev, ok, good to know that the datas are not lost, thanks for the status update
[10:41] <ev> 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] <ev> we often need to iterate back over them as we learn how to do things better or add new features
[10:41] <ev> and big gaps would make future calculations of "are we doing better?" look weird
[10:42] <ev> sure thing though. As always, let me know if anything else is broken
[10:43] <mardy> Laney: thanks! I asked help from the Evolution maintainer, in turn :-)
[10:43] <Laney> :D
[10:47] <mardy> Laney: did you try killing evolution-calendar-factory?
[10:47] <Laney> mardy: for the indicator one?
[10:47] <Laney> (no, but can do)
[10:48] <mardy> Laney: I'd say for both
[10:48] <Laney> ok, let me re-add the account and try
[10:48] <mardy> Laney: I guess they are very strictly related
[10:48] <Laney> yes, I think so
[10:49] <Laney> 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] <mardy> Laney: weird... you are talking about the Google account?
[10:51] <Laney> yes
[10:51] <mardy> Laney: ah, maybe it's not that weird; I think that for the calendar EDS is using a plain username/password authentication
[10:52] <Laney> so it could be choking on my 2fa then?
[10:52] <Laney> killing the calendar factory made me get the same not authorised thing
[10:53] <Laney> mardy: didn't make it work though
[10:53] <Laney> but I suppose this is more information
[10:54] <mardy> Laney: yes, it looks like the username/password is invalid, or anyway not enough to authenticate
[10:54] <mardy> Laney: is that a 2-factor-auth enabled account?
[10:54] <Laney> yep, both are (canonical and personal)
[10:55] <Laney> 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] <dholbach> @pilot out
[10:57]  * Laney remembers that he has an old google account without 2fa
[10:57] <Laney> now, what are the details for that?
[10:58] <xnox> 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] <xnox> Laney: if you don't remember it, #is can reset it for you. (there is no web ui to do it)
[10:59] <Laney> I have the Google account password, but giving that on the "plain" page didn't make it succeed
[10:59] <xnox> =(
[11:01] <ogra> 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] <Laney> mardy: Aha — I added another, non 2fa, account and that seems to work beautifully.
[11:03] <cjwatson> ogra: If you need fixed GIDs then you must coordinate with the Debian base-passwd maintainer
[11:03] <cjwatson> ogra: (i.e. me)
[11:03] <Laney> at least email and calendar in evo, and I got loads of spam friend requests on empathy
[11:04] <cjwatson> ogra: Send mail to base-passwd@packages.debian.org with your requirements and we can talk through them
[11:04] <ogra> cjwatson, i think they are all above 1000, i'm just wondering
[11:04] <Laney> so it seems like the altenate authentication workflow needs more work (even if that's to fail better for now)
[11:04] <cjwatson> 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] <ogra> and i dont have a complete list yet ... only know the wones we use already ... perferably we want them alll though
[11:04] <ogra> cjwatson, well, we dont have much choice ... the GIDs are hardcoded in the kernel
[11:05] <ogra> android is doing bad things here
[11:05] <ogra> but yeah, let me get a full list and i'll mail
[11:05] <cjwatson> Oh, they're specific fixed GIDs forced on you by external forces
[11:05] <cjwatson> That's ... not ideal
[11:05] <ogra> yeah
[11:05] <ogra> thats android :)
[11:06] <ogra> and binary daemons might rely on it
[11:06] <cjwatson> 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] <ogra> right, i'll first discuss that with rsalveti
[11:06] <ogra> in any case i want it in a package postinst instead of having a build script
[11:10] <asac> ogra: dont do bad things - i told you before :-P
[11:10] <ogra> haha
[11:10] <asac> not sure why the good ogra is always doing such things
[11:10] <tkamppeter> OdyX`, I have commented on the bug now.
[11:11] <cjwatson> 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] <cjwatson> 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] <ogra> the issue is that the kernel refuses device access for some bits if the GID doesnt match exactly
[11:12] <cjwatson> Mm.  I thought this was the kind of thing libhybris was supposed to be able to help with.
[11:13] <ogra> i.e. network access is only allowed for GID 3002 3003 3004
[11:13] <ogra> 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] <ogra> radio is similar ...
[11:14] <ogra> live-build/ubuntu-touch/hooks/02-add_user_to_groups.chroot has the current list we use
[11:16] <ogra> (but there are a lot more)
[11:23] <ogra> aha
[11:23] <ogra> found the mapping in the android tree
[11:23] <ogra> http://paste.ubuntu.com/5735451/ should be the full list
[11:23] <ogra> seems to be all above 1000
[11:24] <cjwatson> 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] <ogra> yeah, well
[11:24] <ogra> dont tell me :)
[11:24] <cjwatson> 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] <ogra> we cant hack binary daemons ro drivers that are linked against this
[11:25] <ogra> we could change thee kernel, but that wont fix bianry blobs
[11:25] <ogra> *binary
[11:25] <cjwatson> We could, for example, punt certain kinds of device access behind the scenes through the Android container
[11:25] <ogra> depends if you access stuff directly through a socket or not
[11:26] <cjwatson> You use the C library to create the socket, so ...
[11:26] <ogra> i.e. ofono attaches to the binary vendor rild via a socket
[11:26] <ogra> which has to be the original one from android
[11:26] <ogra> (linked into /dev from the android /dev)
[11:27] <ogra> might be possible to have a wrapper or some such
[11:27] <ogra> but i dont think anyone even throught about GID remapping yet
[11:27] <cjwatson> Somebody might have to :)
[11:27] <ogra> definitely ...
[11:27] <cjwatson> 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] <ogra> yeah, indeed
[11:28] <ogra> the above live-build script has the minimal set we need atm
[11:29] <ogra> (only 10 groups with fixed GID in there atm)
[11:30] <cjwatson> 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] <cjwatson> You can't even use --system since these aren't in the system range
[11:30] <ogra> yeah
[11:31] <cjwatson> Do please use addgroup rather than the low-level groupadd stuff you're doing right now though
[11:31] <cjwatson> And OMG what is all that madness adding global static groups
[11:31] <cjwatson> Most of that script desperately needs to be deleted
[11:32] <ogra> 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] <cjwatson> Heh
[11:32]  * mlankhorst puts cjwatson in AID_UNUSED1
[11:33]  * ogra points out that he is just the messenger ... not my script 
[11:33] <ogra> i just want to clean that up and not have it in the build scripts
[11:33] <cjwatson> Sure, I know, but you can be a messenger in the other direction too :P
[11:33] <ogra> thats what i plan
[11:33] <cjwatson> 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] <cjwatson> Especially not in that invalid way
[11:33] <ogra> i consider sanitizing this part of the container flip
[11:34] <ogra> which as i said above, has no real planning at all yet
[11:34] <cjwatson> And it should use adduser to add the user to that set of groups, not usermod
[11:34] <ogra> yeah
[11:34]  * cjwatson attempts to haul this up to saner levels of the stack
[11:35] <ogra> let me discuss with our android heads first, before we take any action ...
[11:36] <ogra> 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] <ogra> *wouldn't
[11:59] <hallyn> 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] <hallyn> infinity: if you prefer i can ping you before a next update - though i'm hoping i'm done for awhile
[12:02] <hallyn> infinity: i swear i checked for later updates!  but i guess i did that before rebasing - sorry
[12:03] <hallyn> won't happen again
[12:06] <hallyn> (pushing your change to github for good measure0
[12:06] <ogra> bug 1187750
[12:06] <ogra> cjwatson, ^^^
[12:07] <cjwatson> 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] <ogra> cjwatson, definitely
[12:08] <cjwatson> Whoa, what the heck is that stuff with the audio gid :-(
[12:08] <cjwatson> That's going to break as soon as base-passwd is upgraded
[12:08] <ogra> yeah
[12:09] <ogra> thats why the touch images are not officially supporting apt based upgrades i guess :)
[12:10] <cjwatson> Well it's just plain wrong
[12:10] <cjwatson> 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] <ogra> android_audio then ... though that will obsolete the normal audio group
[12:12] <cjwatson> Better to obsolete it than to screw it over
[12:12] <ogra> indeed
[12:19] <ogra> asac, you might want to monitor the ablve bug too probably
[12:19] <ogra> *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] <ogra> (in live-build/ubuntu-touch/hooks/48-setup-env.chroot )
[12:23] <cjwatson> mm, that seems like it should be set by a session script or something
[12:23] <cjwatson> SHLVL=1 ???
[12:23] <cjwatson> Did somebody run env and copy and paste, or something?
[12:24] <ogra> could be
[12:24] <sergiusens> cjwatson: ogra I already removed some gid checking which you never saw, like access to surfaceflinger or sensors
[12:24] <ogra> i have no idea how these scripts were developed initially
[12:24] <ogra> it predates my involvement
[12:25] <sergiusens> for audio, I'm guessing most of it will go away once jim finishes up his native ubuntu audio integration
[12:25] <ogra> sergiusens, well, the question is what do we really need
[12:25] <sergiusens> rild is a pain though
[12:25] <ogra> i assume for everything that talks directly to an android socket like rild we wont get around having the groups
[12:25] <ogra> yeah
[12:26] <ogra> but for all other stuff we might be able to find a better solution
[12:26] <cjwatson> 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] <ogra> or even have a wrapper on the ubuntu side that does some re-mapping or so
[12:27] <ogra> cjwatson, well, android obviously uses its header files ... but i know that the kernel also uses some of this
[12:27] <ogra> the prob are really the binary bits we dont have contol over ... though only if we talk to them directly
[12:27] <sergiusens> 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] <ogra> sergiusens, whats your solution ?
[12:28] <sergiusens> ogra: let me look at it first and then propose something ;-)
[12:28] <ogra> 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] <sergiusens> ogra: so gps creates an IPC socket on manta on /data
[12:29] <sergiusens> the binary blob that is
[12:30] <sergiusens> so let me consolidate all the cases we have and see if I can factor something common for all
[12:33] <infinity> hallyn: S'all good, was just mildly annoyed when I saw component-mismatches explode again.
[12:35] <ogra> though i dont know if there is more than rild .... i guess there is a reason why we have 10 groups already ... they are definitely not all rild related
[12:43] <cjwatson> mitya57,seb128,xnox: the insighttoolkit4 build failure isn't making a lot of sense to me, partly because I don't know cmake that well.  Can any of you help?  At first glance I thought it was basically a missing build-dep on libvtkgdcm2-dev, but I don't think that's right - insighttoolkit4 doesn't really need it, and if you compare with e.g. ...
[12:43] <cjwatson> ... https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit4&arch=sparc&ver=4.3.2-1&stamp=1367450169 (yes, it fails later, but ignoring that), there's the same message about /usr/lib/libvtkgdcm.so.2.2.3 but it's non-fatal
[12:44] <cjwatson> indeed even building insighttoolkit4 on current unstable seems to succeed, or at least get well past the configuration step
[12:44] <cjwatson> so I don't understand what's different between Debian and Ubuntu here
[12:45] <cjwatson> cmake is identical, and neither the gdcm nor insighttoolkit4 changes seem relevant
[12:46] <zul> cjwatson: hi can you promote python-mimeparse python-testtools is in dep wait because of it (mir https://bugs.launchpad.net/ubuntu/+source/python-mimeparse/+bug/1187527)
[12:48] <cjwatson> zul: done
[12:48] <zul> cjwatson:  thanks
[12:59] <ion> mvo: Hi. Are you around?
[13:01] <mvo> hey ion, yes
[13:02] <ion> mvo: Does this look okay? ttps://github.com/ion1/apt/commits/debian/sid
[13:02] <ion> Err. https://github.com/ion1/apt/commits/debian/sid
[13:05] <wzssyqa> doko: hi, any idea about howto get multilib bootstrap?
[13:06] <doko> context?
[13:06] <mvo> ion: from a first look yes, thanks! will you propose it for merging?
[13:07] <seb128> mvo, hey, how are you?
[13:07] <ion> mvo: Do i need to do something special to get it merged or can you just do it?
[13:07] <seb128> mvo, do you plan to merge apt on the current Debian version at some point?
[13:07] <mvo> seb128: can do, sure! I'm well, thanks
[13:08] <seb128> mvo, thanks ;-)
[13:08] <seb128> mvo, glatzor: do you know if anyone is porting aptdaemon to the pkgkit 0.8 interfaces?
[13:11] <mvo> ion: I can just do it, there is a small "send pull request" or something that you can use to make it easier for me to not forget about it
[13:15] <glatzor> hello seb128, mvo. Actually yes: me :)
[13:15] <seb128> glatzor, hey, how are you?
[13:15] <glatzor> seb128, mvo I am currently on vacations and hopefully will find some time tomorrow or the day after to continue the work. I already started the port. But the interface changed really a lot.
[13:16] <seb128> glatzor, great, are you still working on it (the vcs pointed on the blueprint we found didn't get any commit this year) ... do you have an estimate on how much work that is/when it will be ready?
[13:16] <glatzor> seb128, I am fine!
[13:16] <glatzor> seb128, perhaps end of month to get it stable.
[13:17] <glatzor> seb128, do you need the packagekit 0.8 client library?
[13:17] <seb128> glatzor, I'm asking because we got the new packagekit uploaded and we were wondering if we should revert that or try to go through the transition
[13:17] <glatzor> seb128, revert it for the moment
[13:17] <seb128> glatzor, it's currently blocked in saucy-proposed
[13:17] <seb128> Laney, pitti, cjwatson: ^
[13:17] <glatzor> seb128, that is my suggestion
[13:18] <pitti> right, so same conclusion that we had yesterday
[13:18] <pitti> hey glatzor, wie gehts?
[13:18] <seb128> cjwatson, btw saw your ping about cmake, I'm not really fluent in cmake either but I can try having a look a bit later if mitya57/xnox don't ping back/have a clue about the issue
[13:18] <glatzor> pitti, supi! could not be better. The sun is shining here in Bavaria!
[13:19] <glatzor> pitti, and even in Scotland we only had one hour of rain in a whole week
[13:19] <pitti> glatzor: I know, at last! I'm enjoying it since yesterday, too (Augsburg)
[13:21] <doko> wzssyqa, context?
[13:21]  * rsalveti checking backlog
[13:26] <ion> mvo: I actually tried making a pull request to you when i noticed you have a github account, but since my repo isn’t already a fork of yours, github doesn’t seem to allow that. Let me delete the repo, fork yours and push again, a moment…
[13:27] <wzssyqa1> doko: I am working on mips64(el) ports, and the system can bootstrap now, while I have no idea about how to break the cycle of eglibc and gcc to enable multilib
[13:27] <rsalveti> cjwatson: ogra: sergiusens: I believe we can come up with a mix of disabling group/user id checking and handling weird setups (and binary blobs) via libhybris
[13:27] <rsalveti> in a way we could indeed have a better setup than just matching user and group ids
[13:27] <rsalveti> it's just that we never really spent any time on that
[13:27] <ogra> rsalveti, yeah, i was guessing so, but waht about stuff that talks directly to i.e. rild ?
[13:27] <rsalveti> I can take a better look in more details later today and see what can be done on the android side
[13:28] <ion> mvo: mvo5, correct?
[13:28] <mvo> ion: yeah
[13:28] <rsalveti> ogra: that's fine, we just need to change the permission for the sockets
[13:28] <rsalveti> for sockets we'd need a script or something anyway as we'd need to either link or bindmount the /dev/socket from android
[13:28] <ogra> well, we only get the sockets by linking the /dev/socket dir from android to /dev
[13:28] <rsalveti> as that's created by android
[13:28] <ogra> if we chjange them on our side it might break
[13:29] <rsalveti> right, and we can probably do something smart there to change the default permission as well
[13:29] <rsalveti> I don't think so
[13:29] <doko> wzssyqa, is this for Ubuntu?
[13:29] <ogra> lxc-android-config already links /dev/socket
[13:29] <rsalveti> ogra: also, we might need to create a group for modem or such anyway (if we don't have it already)
[13:29] <ogra> but indeed doesnt change any permissions yet
[13:29] <ogra> we have dip and dialout iirc
[13:29] <rsalveti> I'm not worried about that at all, after all they are just sockets
[13:30] <ogra> well, if rild gets along with it
[13:30] <rsalveti> and we can hook up functions to check group and user id in hybris
[13:30] <wzssyqa1> doko: ubuntu and debian share the same eglibc and gcc, right?
[13:30] <ogra> tony got mew scared with his complaining over the last weeks :)
[13:30] <rsalveti> and do the matching there if really needed
[13:31] <rsalveti> ogra: well, I believe we should be fine, I'll be checking ril/ofono support with todays image later today
[13:31]  * ogra reboots into todays flipped image and prays the shell will come up automatically 
[13:31] <rsalveti> with the flip container, just to be sure it works
[13:31] <ogra> sigh
[13:31] <ogra> seems it doesnt :(
[13:31] <mitya57> cjwatson: "internal compiler error: Segmentation fault" on powerpc? not a pleasure to debug...
[13:31] <rsalveti> ogra: I can easily test ofono without the shell :-)
[13:31] <ogra> hah, but having adbd use bash is so much cooler ... thanks stgraber
[13:32] <ogra> hmm, seems everything butt the shell came up
[13:35] <ogra> bah ... was just missing an rm
[13:35] <doko> yes
[13:35] <ogra> sigh
[13:41]  * mitya57 realized that he was looking at wrong log
[13:42] <teolemon> Hi, I was wondering in which channel I could contact somebody from the ubuntu.com infrastructure (to install a webapp on ubuntu.com)
[13:45] <cjwatson> mitya57: meh, I was thinking of the i386 failure
[13:45] <mitya57> cjwatson: "* mitya57 realized that he was looking at wrong log"
[13:46] <cjwatson> ah
[13:48] <wzssyqa1> doko: then, I tried to cross build eglibc with clang. I also tried to build it with the gcc-multlib from mipsel.  all of them failed
[13:54] <doko> wzssyqa1, sorry, can't help you with that. bootstrapping, not much time. you may want to look at the powerpc-cross-toolchain-base and gcc-4.8-powerpc-cross packages in ubuntu
[13:54] <wzssyqa1> doko: thanks
[14:07] <ev> bdmurray: https://oops.canonical.com/reports/WHOOPSIE-PROD/
[14:07] <ev> ^ that's the new home of the OOPS reports. /oops-local is dead.
[14:07] <ev> (though it's remains for hysterical raisins
[14:08] <mitya57> cjwatson: GDCMTargets.cmake hasn't changed since raring, so it looks like new CMake made missing files cause an error instead of warning
[14:09] <mitya57> cjwatson: does it build in sid with new CMake?
[14:09] <mitya57> Let me test myself
[14:09] <cjwatson> it builds in current sid
[14:09] <cjwatson> with whatever's default there
[14:10]  * xnox is somehow guessing that vtk needs rebuild against python2.7.5 and I'm not sure how gdcm managed to build correctly without a rebuilt vtk.
[14:10] <cjwatson> may be true but I'm not sure how it relates to this cmake weirdness?
[14:10] <xnox> (that rebuild needs to happen regardless, but it might not help insighttoolkit at all)
[14:17] <mitya57> cjwatson: yes, it is really a change in cmake: http://paste.ubuntu.com/5735889/
[14:18] <mitya57> so my suggestion will be to add that B-D
[14:19] <xnox> mitya57: but with that b-d installed, it still FTBFS.
[14:19] <mitya57> it adds: 'message(FATAL_ERROR "The imported target \"${target}\" references the file \"${file}\"'
[14:19] <Laney> what's that a diff of?
[14:20] <mitya57> Laney: a diff between usr/lib/gdcm-2.2/GDCMTargets.cmake in sid and saucy
[14:20] <mitya57> xnox: with the same error?
[14:20] <xnox> mitya57: hm? the diff between saucy-proposed and sid is none: http://paste.ubuntu.com/5735895/
[14:21] <xnox> damn, nothing in saucy-proposed.
[14:21] <xnox> i mean between: libgdcm2-dev_2.2.3-1_amd64.deb in sid, and        libgdcm2-dev_2.2.3-1ubuntu2_amd64.deb in ubuntu
[14:24] <Laney> actually it seems it is different
[14:24] <Laney> the first change in the diff is probably the clue
[14:25] <xnox> Laney: hmm. true.
[14:25]  * xnox thought debdiff did recursive diff as well, I guess not.
[14:25] <bdmurray> seb128: ah, thanks I'll have a look
[14:26] <Laney> doesn't diff the files inside, no
[14:26] <mitya57> xnox: do you have a build log of that in saucy with the b-d added?
[14:26] <bdmurray> ev: the oops report is great
[14:27] <xnox> Laney: gdcm should get binNMU in Debian then.
[14:27] <seb128> bdmurray, hey, thank you
[14:27] <bdmurray> ev: oh, but the links don't work?
[14:30] <ev> bdmurray: the ones up top don't yet, but the ones on the far right do
[14:31] <ev> and then there are the urls in the middle for the request itself which will never work (though maybe we can fix that, even though it doesnt make sense clicking them for daisy.ubuntu.com)
[14:31] <ev> it would for errors.u.c though
[14:37] <mitya57> there's something wrong with freenode today...
[14:38] <Laney> mitya57: CMake Error at /usr/lib/gdcm-2.2/GDCMTargets.cmake:155 (message):
[14:38] <Laney>   The imported target "php_vtkgdcm" references the file
[14:38] <Laney>      "/usr/lib/vtkgdcm.so"
[14:38] <Laney>   but this file does not exist.  Possible reasons include:
[14:39] <cjwatson> right, but the same thing is a warning in an unstable build
[14:39] <Laney> yes, we established that gdcm's rebuild in Ubuntu caused it to regenerate its .cmake file which upgraded such things to errors
[14:40] <pitti> cjwatson: with just the two removals and two rebuilds in -proposed for reverting PackageKit, do you think we need any particular magic there? (the rebuilds will just be -0ubuntu2)
[14:40]  * pitti bbl
[14:41] <mitya57> ... because we have only /usr/lib/libvtkgdcm.so.2.2
[14:41] <Laney> libvtkgdcm.so -> that, yes
[14:41] <cjwatson> pitti: I think that's OK - just make sure the removal has been published before uploading the reverts
[14:41] <mitya57> Laney: should we add that symlink?
[14:41] <cjwatson> pitti: and you might want to sync-blacklist or something so it stops showing up on merges.u.c
[14:41] <Laney> I don't know
[14:41] <Laney> why is it looking for the wrong file?
[14:42] <bdmurray> pitti, ev: re bug 1187723 it works for releases other than 13.10
[14:42] <ev> hmm
[14:42] <bdmurray> https://errors.ubuntu.com/?user=pitti&period=month
[14:42] <cjwatson> Laney: I think it's a cmake file that has basically a bunch of optional imports
[14:43] <cjwatson> use these if they're here
[14:43] <Laney> see mitya57's earlier pastebin
[14:43] <Laney> it's the diff of the relevant .cmake file between sid and saucy showing that some things were upgraded to errors
[14:44] <Laney> at least that's how my cmake-stupid brain reads it
[14:44] <slangasek> seb128: update-manager gsettings> ack
[14:44] <slangasek> bdmurray: will you take care of fixing update-manager too, then?
[14:44] <slangasek> pitti: binutils> sweet :)
[14:45] <bdmurray> slangasek: yes
[14:51] <mitya57> Laney: err, libvtkgdcm2-dev does ship that symlink (proof: http://packages.ubuntu.com/raring/i386/libvtkgdcm2-dev/filelist), how can it happen that that file is missing?
[14:52] <Laney> note the 'lib'
[14:52] <mitya57> oh
[14:55] <cjwatson> and libgdcm2-dev doesn't depend on libvtkgdcm2-dev, but vice versa
[14:56] <Laney> php5-vtkgdcm installs -rw-r--r-- root/root    748680 2013-06-03 09:27 ./usr/lib/php5/20100525+lfs/vtkgdcm.so
[14:56] <Laney> xnox is trying his best to get this stuff removed from testing ;-)
[14:56] <mitya57> :)
[14:57]  * mitya57 's cmake knowledge ends here
[15:00]  * Laney glares at freenode
[15:00] <xnox> slangasek: what's your value of /proc/sys/vm/dirty_ratio ?
[15:03] <mitya57> I think it's a bad idea to have /usr/lib/vtkgdcm.so -> /usr/lib/php5/20100525+lfs/vtkgdcm.so symlink, as it's a php-specific library and shouldn't be exposed to the system
[15:04] <mitya57> so we need to add more search paths to cmake instead
[15:05] <slangasek> xnox: so based on that side conversation... I guess you don't have /tmp on tmpfs?
[15:07] <xnox> slangasek: no, since I was affected by "it takes to long to clear /tmp" bug which you weren't affected by.
[15:07] <Laney> mitya57: gdcm's rules file manually moves it out of /usr/lib/ to that location
[15:08] <mitya57> ... so we can't blame upstream
[15:08] <Laney> At this point you probably need some cmake to get php5-vtkgdcm to leave the right trail behind for its consumers
[15:09] <Laney> Might just be sensible to take these findings to debian-med and let them deal with it...
[15:10] <mitya57> Let's file a bug then?
[15:10] <slangasek> xnox: ah right :)
[15:10] <Laney> please do
[15:10] <Laney> maybe confirm it breaks rdeps after a rebuild though
[15:19] <doko> infinity, https://launchpadlibrarian.net/141721049/buildlog_ubuntu-quantal-amd64.gcc-4.8_4.8.1-2ubuntu1~12.10_FAILEDTOBUILD.txt.gz
[15:19] <doko> In file included from /usr/include/fenv.h:58:0,
[15:19] <doko>                  from ../../../../src/libquadmath/math/ccoshq.c:23:
[15:19] <doko> ../../../../src/libquadmath/math/ccoshq.c: In function 'ccoshq':
[15:19] <doko> /usr/include/bits/fenv.h:116:4: error: impossible constraint in 'asm'
[15:19] <doko>     __asm__ __volatile__ ("divss %0, %0 " : : "x" (__f));
[15:19] <doko>     ^
[15:19] <doko> /usr/include/bits/fenv.h:116:4: error: impossible constraint in 'asm'
[15:19] <doko>     __asm__ __volatile__ ("divss %0, %0 " : : "x" (__f));
[15:19] <doko>     ^
[15:19] <doko> didn't we fix that in eglibc? or is it not yet there?
[15:23] <infinity> doko: SRU not uploaded for that yet, I should do that this week.  Was waiting to queue up a few things in one go.
[15:42] <bdmurray> barry: were you still going to have a look at bug 1094218?
[16:00] <slangasek> barry: yeah, meeting ended ;)
[16:28] <kenvandine> @pilot in
[17:20] <smoser> slangasek, around ?
[17:20] <smoser> i'm guessing that jodh is not
[17:20] <smoser> so you're the next best thing :)
[17:21] <slangasek> smoser: ohai
[17:21] <smoser> we're seeing an issue on raring upstart
[17:22] <smoser> cloud-config is not running
[17:22] <smoser> but it is : start on (filesystem and started rsyslog)
[17:22] <smoser> and rsyslog *is* started (rsyslog start/spawned, process 1656)
[17:23] <smoser> and it's start on is: start on filesystem
[17:23] <smoser> so it would appear to me that cloud-config should have started.
[17:31] <smoser> slangasek, ^
[17:32] <slangasek> smoser: ok; so is mountall still running?
[17:32] <smoser> stop/waiting
[17:32] <slangasek> smoser: and is there any chance this is still another problem with upstart getting re-execed or config-reloaded and dropping in-flight events?  The fix for that is just about to land in raring SRU, but it's not there yet
[17:34] <smoser> slangasek, i dont think so. as cloud-config would be the thing that would do an upgrade.
[17:34] <slangasek> hmm
[17:34] <smoser> and i dont see anything that cloud-inti woudl have done to initcitl reload
[17:34] <smoser> i can let you in
[17:34] <slangasek> ok
[17:46] <sil2100> jamesh: ping!
[17:50] <seb128> sil2100, it's like 2am for him, probably not the best time to have a pong
[17:50] <sil2100> seb128: ACK, thanks
[17:51] <smoser> slangasek, jamespage opened as bug 1187876
[17:53] <slangasek> smoser: and this failure is frequently reproducible on the affected machine?
[17:53] <smoser> http://lists.adiscon.net/pipermail/rsyslog/2012-January/029268.html maybe relevant.
[17:53] <smoser> jamespage, ^
[17:53] <smoser> how frequent is this ?
[17:57] <smoser> bah. that is reported fixed in 5.8.7 and we're 5.8.11 there.
[17:59] <smoser> slangasek, i say give it a try (reboot) and see.
[18:02] <jamespage> smoser, slangasek: 11/12 of the last first boots on the effected hardware
[18:02] <sil2100> barry: ping!
[18:07] <slangasek> smoser: rebooted, it seems to be taking its sweet time coming back up
[18:09] <slangasek> smoser, jamespage: ok, reproduced on reboot
[18:10] <smoser> slangasek, those systems take like 2 minutes to post
[18:10] <slangasek> cute
[18:12] <ion> Awesome, someone has made libappindicator bindings for Haskell.
[18:14] <infinity> ion: I'm not sure you're using that word correctly.
[18:14] <slangasek> because what indicators needed was greater uncertainty about how long things will take to display correctly
[18:15] <ion> infinity: “has”? “bindings”? “someone”?
[18:15] <infinity> ion: "awesome". :P
[18:16] <ion> infinity: Ok, let me rephrase it: “Excellent!”
[18:50] <slangasek> smoser: regression in the SRU from bug #1022545, which has an off-by-one error in its string handling.
[18:50] <slangasek> smoser: not sure yet this is the cause of the malloc failure, but it looks probable as this is the only complaint out of valgrind
[18:52] <cjwatson> ion: I think it would be a bad idea to upload Ubuntu-specific Haskell bindings, given how much we rely on Debian to keep that subsystem at all workable.
[18:52] <cjwatson> Although I see libappindicator is in Debian - but an old version I think
[18:53] <ion> I’m actually not using the system packages at all for Haskell development, i also cabal installed happindicator under ~. Seems to work fine.
[18:54] <slangasek> smoser: right, confirmed here that unapplying that patch fixes it.  So, critical SRU regression. :P  Thanks for raising this.
[18:59] <infinity> slangasek: Added precise and raring tasks to https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1187808 due to your above conversation.
[19:00] <slangasek> infinity: ack.
[19:00] <Laney> ion: Since you only got negative comments - COOL! :-)
[19:01] <ion> heh
[19:01] <infinity> slangasek: Want to prep the 1-char fixes, or review them if I do it (I'd rather not be on the hook for verification, since I haven't bothered to reproduce).
[19:01] <slangasek> caribou: please see above wrt the recent rsyslog SRU.  Do you happen to have the upstream git to hand, and is there a follow-up fix that we should take?
[19:02] <infinity> slangasek: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff_plain;h=9c54bf41d02ba236137859ea5f12d6f048647349
[19:02] <infinity> slangasek: Referenced in the bug.
[19:02] <slangasek> ok
[19:02] <slangasek> infinity: I'll take care of the uploads
[19:03] <infinity> slangasek: Alright.  If you do 'em quick, I'll review before I head out for the afternoon.
[19:04] <infinity> slangasek: And this seems like a valid case for expediting the accept/verify/release turnaroud, if you can find someone to verify.
[19:05] <slangasek> I can verify it directly
[19:12] <dobey_> is there no easy way to fix broken package import branches?
[19:12] <slangasek> no.
[19:12] <slangasek> barry: ^^ do you know who, if anyone, is still minding the store on those?
[19:31] <cjwatson> slangasek: wgrant and xnox are the people I go to for those
[19:31] <slangasek> ok
[19:31] <slangasek> dobey: ^^ maybe that helps?
[19:32] <cjwatson> It has to some extent been borged into LP maintenance
[19:33] <dobey> hmm, ok
[19:34] <barry> slangasek: you can perhaps beg someone on #udd but otherwise, you will have a sad
[19:34] <barry> (maybe the udd mailing list too)
[19:34] <barry> but in general, nobody is
[19:35] <cjwatson> barry: I think it's better than that.  William in particular has been fixing a fair few problems AIUI.
[19:35] <barry> cjwatson: that is *great* news!  wgrant ftw
[19:35] <seb128> bdmurray, what's the need of dropping that key from the update-notifier schemas rather than marking it deprecated? did you grep the archive in case anything else is relying on it?
[19:36] <seb128> bdmurray, it's just 5 lines of text in a .xml, I though it would have been easier to keep it flagged as deprecated than dropping it, especially when missing key is abort() reason for gsettings
[19:36] <seb128> it's sort of an "abi" break for no real benefit
[19:37] <slangasek> infinity: rsyslog uploaded for saucyraringprecise
[19:37] <infinity> slangasek: Yeahp, queuebot told me.
[19:37] <slangasek> k
[19:38] <ogra> saucyraringprecise ? is that the new name for the rolling dev release ?
[19:38] <slangasek> seb128: well, nothing should be using that setting; the fact that things fail in its absence may have come as a surprise to us, but it's better to root out any references to that key and fix them all at once
[19:38] <ogra> :)
[19:38] <seb128> slangasek, ok, so you are archive greping for other users of the key if there is any?
[19:38] <infinity> I prefer presaucing.
[19:39] <dobey> infinity: one must sauce precisely.
[19:40] <infinity> Trying so hard to not say "that's what she said" right now.
[19:42] <slangasek> seb128: the likelihood of anything other than u-m and u-n using this key is so small that I'm not sure it's worth the time of doing that, vs. just letting any bugs be found and reported
[19:42] <seb128> slangasek, ok, wfm
[19:42]  * seb128 checks software-center and aptdaemon in case
[19:43] <seb128> slangasek, btw I tagged/pushed your upload to the vcs of update-notifier to be able to add my fix on top, hope it's ok ;-)
[19:43] <bdmurray> I'll check the archive just in case
[19:43] <glatzor> seb128, aptdaemon doesn't use it
[19:44] <seb128> glatzor, saw that, thanks
[19:44] <glatzor> seb128, but I don't know about s-c
[19:44] <seb128> neither does s-c
[19:44] <glatzor> ok
[19:44] <slangasek> seb128: which upload?  I think bdmurray did the last u-n upload
[19:44] <seb128> slangasek, the one from yesterday that dropped the key
[19:44]  * barry returns to the porch for some quality time with gpg
[19:45] <bdmurray> seb128: what branch are you using?
[19:45] <seb128> slangasek, oh, sorry, bdmurray uploaded it seems, I saw your name at the top of the changelog...
[19:45] <seb128> bdmurray, ~ubuntu-core-dev/update-notifier/ubuntu/
[19:45] <slangasek> ok, seriously, who broke 'bzr info'?
[19:45] <seb128> bdmurray, the one listed in debian/control
[19:45] <bdmurray> seb128: we've been using
[19:46] <bdmurray> er nevermind
[19:46] <seb128> bdmurray, well, this morning it was UNRELEASED, maybe you forgot to push the commit where you flagged it as a release?
[19:46] <seb128> everything else was current
[19:46] <bdmurray> seb128: yeah, I fixed that and merged your 0.137 changes
[19:46] <seb128> hum
[19:46] <seb128> I had pushed my changes to the vcs
[19:47] <seb128> did you overwrite?
[19:47] <seb128> bzr: ERROR: These branches have diverged. Use the missing command to see how.
[19:47] <seb128> Use the merge command to reconcile them.
[19:47] <seb128> shrug
[19:47] <bdmurray> hmm, I did an updated before pushing...
[19:47] <seb128> or maybe I forgot to push as well :p
[19:47] <seb128> anyway no worry
[19:47] <doko> seb128, on raring:
[19:47] <doko> Setting up libgtk2.0-0:armhf (2.24.17-0ubuntu2) ...
[19:47] <doko> /usr/lib/arm-linux-gnueabihf/libgtk2.0-0/gtk-query-immodules-2.0: 1: /usr/lib/arm-linux-gnueabihf/libgtk2.0-0/gtk-query-immodules-2.0: Syntax error: word unexpected (expecting ")")
[19:47] <seb128> seems to be alright now
[19:47] <seb128> bdmurray, thanks
[19:47] <doko> is this expected?
[19:48] <doko> armhf is the foreign arch
[19:48] <seb128> doko, no, and not seen before ... is that consistent or a one time error? the arm builders tends to have corrupted datas sometimes it seems
[19:49] <doko> no, that's a local install
[19:49] <slangasek> doko: that's the postinst trying to exec the foreign-arch indexer
[19:49] <slangasek> there's a || true after it in the postinst, but it'll still spit out errors
[19:49] <slangasek> I've never seen that particular error before fwiw
[19:49] <doko> ahh, yes I see
[19:49] <slangasek> but if you don't have armhf qemu support in place, errors of /some/ kind are expected
[19:51] <infinity> slangasek: Alright, acceptiferated, and I'm heading off for a bit.  Give me a nick highlight nudge when you're satisfied it's all verified.
[20:32] <smoser> cjwatson, are you around ?
[21:00] <cjwatson> smoser: not really, e-mail?
[21:00] <cjwatson> Unless it's really quick
[21:00] <smoser> sure.
[22:05] <xnox> dobey: i'm not an expert, but which package are you after? I can take a look.