[15:18] <satellit_> dfarning: I hope it is ok I uploaded http://people.sugarlabs.org/Tgillard/USR-i386-20100804.iso for a temp DL site with http://people.sugarlabs.org/Tgillard/Surf-115.xo
[15:18] <satellit_> since they work fine
[15:18] <dfarning> satellit_, thanks.
[15:20] <satellit_> tested here for activities: http://wiki.sugarlabs.org/go/Features/Soas_V4/ASLOxo_Activity_Test_Table#Activity_Test_Results
[15:28] <satellit_> dfarning: https://wiki.ubuntu.com/Sugar  still lists http://people.sugarlabs.org/dfarning/ as Download site....has http://people.sugarlabs.org/dfarning/USR-i386-20100208.iso  anyway to update this? to 804?
[15:29] <satellit_> copy from Tgilliard to your sunjammer site...
[15:29] <dfarning> satellit_, better yet, you can point the wiki to your site:)
[15:30] <satellit_> not sure I have access...
[15:30] <satellit_> will try
[15:30] <dfarning> satellit_, I think you have a much better understanding of ISOs than I do.
[15:31] <lfaraone> morning dfarning.
[15:31] <dipankar> dfarning, hello. Good morning
[15:31] <dipankar> lfaraone, hey, good morning
[15:31] <dfarning> lfaraone, dipankar good morning
[15:33] <dipankar> dfarning, I need your help a bit. It would be great if you could please edit the bug description, and add the required information: https://bugs.launchpad.net/ubuntu/+source/sugar-0.88/+bug/621896
[15:33] <ubot2> Launchpad bug 621896 in sugar-0.88 (Ubuntu) "Sugar emulator crashes while copying file from usb drive to journal (affects: 1) (heat: 6)" [Medium,Incomplete]
[15:35] <dfarning> dipankar, sure it will take a while.
[15:35] <dipankar> dfarning, thanks a lot!
[15:39] <lfaraone> dfarning: I'll author an email explaining the status of Browse/Surf in Ubuntu as I understand it.
[15:39] <dfarning> lfaraone, thanks.
[15:46] <satellit_> dfarning: done https://wiki.ubuntu.com/Sugar  changed links
[15:47] <dfarning> satellit_, thanks
[15:47] <satellit_> yw
[17:57] <dipankar> dfarning, around?
[17:57] <dfarning> dipankar, yes
[17:59] <dipankar> dfarning, I was thinking if I can add the info on the bug https://bugs.launchpad.net/ubuntu/+source/sugar-0.88/+bug/621896 myself :)
[17:59] <ubot2> Launchpad bug 621896 in sugar-0.88 (Ubuntu) "Sugar emulator crashes while copying file from usb drive to journal (affects: 1) (heat: 6)" [Medium,Incomplete]
[17:59] <dipankar> dfarning, for that I need some pointers, how did that bug happen? and what were the actions that you performed.
[18:00] <dfarning> dipankar, I am sorry that will not get to that until tommorrow.  manusheel and I are doing stratigic planing base on what I learned in PY:)
[18:01] <dfarning> dipankar, I will start daily operations stuff tomorrow.
[18:01] <dipankar> dfarning, no problem :) you can just tell me what you did in short to reproduce the bug. I will add them to the bug :)
[18:03] <dipankar> dfarning, oops. sorry. I think I missed your last statement. No problem
[18:03] <dfarning> dipankar, I just droped and dragged some icons from the journal to the USB icon in the lower left of the frame.  After a couple of times sugar crashed and the errorlog was the last error sent.
[18:03] <dipankar> dfarning, thanks for taking out some time. I will add it to the bug right now
[18:03] <dfarning> dipankar, thanks.
[18:04] <dipankar> dfarning, whats PY btw? sorry for my ignorance
[18:04] <dfarning> dipankar, Paraguay.
[18:05] <dfarning> dipankar, UY is uraguay.
[18:05] <dipankar> dfarning, ohk. Nice short forms.  :)
[18:19] <dipankar> lfaraone, I have changed the description of bug on lp: https://bugs.launchpad.net/ubuntu/+source/sugar-0.88/+bug/621896
[18:19] <ubot2> Launchpad bug 621896 in sugar-0.88 (Ubuntu) "Sugar emulator crashes while copying file from usb drive to journal (affects: 1) (heat: 6)" [Medium,New]
[18:36] <manusheel> alsroot: Hi Aleksey.
[18:37] <manusheel> Around?
[18:37] <alsroot> manusheel: hi
[18:42] <manusheel> alsroot: Can you join #seeta channel too?
[18:43] <dipankar> alsroot, hi, good morning
[18:43] <manusheel> alsroot: Thank you. Appreciate it.
[18:43] <alsroot> np
[18:47] <dipankar> alsroot, around?
[18:47] <alsroot> dipankar: yup
[18:48] <dipankar> alsroot, I am working on a feature request "Allow multiple file operations in journal"
[18:48] <dipankar> alsroot, I need to learn about copying specifically
[18:49] <dipankar> alsroot, I found the package to be sugar-0.88, but how do I know, rather how do I track the exact file?
[18:49] <dipankar> alsroot, by now, I have just reached to the folder /src/journal
[18:49] <dipankar> is it correct folder to start with any journal operation?
[18:51] <alsroot> dipankar: in any case you need to know how to write file to/from ds
[18:52] <alsroot> dipankar: you can find ds related code in sugar-tolkit, in src/sugar/datastore
[18:52] <dipankar> * ds -> datastore?
[18:53] <alsroot> dipankar: yup
[18:54] <alsroot> dipankar: or, if you prefer, look into sugar, src/jarabe/journal/model.py:write()
[18:54] <alsroot> it does the same
[18:55] <alsroot> dipankar: in the same file, there is cope() function, to know how to implement copy related feature in UI, just grep for copy invocation
[18:55] <alsroot> *copy()
[18:56] <dipankar> alsroot, thanks, I will get back to you in secs. * I remember, you are the journal maintainer
[19:07] <dipankar> alsroot, I am trying to understand the code
[19:07] <dipankar> alsroot, copy func needs two things : metadata and mount_point
[19:11] <alsroot> dipankar: yup, "/" mountpoint means ds
[19:12] <dipankar> alsroot, so this copy is actually the one for copy to clipboard (right click one) or the copy to a usb (drag and drop)
[19:13] <alsroot> dipankar: that doesn't matter, just object metadata is pointing to (it could ds or non-ds object)
[19:15] <dipankar> alsroot, that means the cases that we want depend on the argument sent?
[19:15] <dipankar> for mount_point?
[19:16] <alsroot> dipankar: yup, mount_point is destination
[19:18] <dipankar> alsroot, the feature request says " to allow multiple files working at same time"
[19:19] <dipankar> alsroot, how can this be done, any pointers?
[19:20] <alsroot> dipankar: in fact, from ds side, you can use async dbus calls
[19:20] <dipankar> alsroot, like somewhat similar to multi threading?
[19:21] <alsroot> dipankar: for fs, you need to use gio I think
[19:21] <alsroot> dipankar: nope, dbus will use glib main loop
[19:21] <alsroot> ..gio as well
[19:22] <alsroot> http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html
[19:23] <alsroot> see also http://library.gnome.org/devel/gio/stable/
[19:28] <ebordon> hi all
[19:29] <ebordon> can I install usr from usb key?
[19:35] <dipankar> ebordon, hi
[19:36] <dipankar> alsroot, thats a bit confusing
[19:36] <dipankar> :(
[19:36] <ebordon> dipankar: how are you?
[19:36] <dipankar> ebordon, I am doing great. How are you?
[19:37] <dipankar> ebordon, I think dfarning is not here at the moment. could you please tell me what you mean by 'usb key'?
[19:37] <ebordon> dipankar: I'm fine, I'm trying to install usr on a classmate :o
[19:37] <alsroot> dipankar: well, it is basic thing that every gobject/gtk developer should know
[19:38] <alsroot> ..I mean about loops
[19:38] <neeraj> lfaraone: hi.
[19:38] <dipankar> alsroot, ohk, I will go through it once again.
[19:38] <ebordon> dipankar: Laptop that I want to install usr haven't cd reader
[19:39] <ebordon> dipankar: and i want install it from a pendrive
[19:39] <dipankar> ebordon, ohk. Do you have a desktop or another laptop?
[19:41] <ebordon> dipankar: laptop (classmate JumPc) with ubuntu
[19:41] <ebordon> dipankar: I think 9.10
[19:41] <lfaraone> neeraj: yes?
[19:42] <neeraj> lfaraone: regarding mouse bug. I have added the patch on LP. https://bugs.launchpad.net/ubuntu/+source/sugar-0.88/+bug/511225
[19:42] <ubot2> Launchpad bug 511225 in sugar-0.88 (Ubuntu) "running sugar causes left-click not to work properly in GNOME (affects: 2) (heat: 20)" [Undecided,Confirmed]
[19:43] <ebordon> dipankar: sorry for my english, it is really bad
[19:43] <neeraj> lfaraone: as the patch is already present in sugarlabs, we don't need it to send it there.
[19:44] <dipankar> ebordon, your english is absolutely fine :) don't worry about that. I am thinking of a simplest way to install usr
[19:45] <lfaraone> neeraj: great. was it cherrypicked from upstream, did you author it yourself, etc.
[19:45] <dipankar> ebordon, you can use synaptic package manager if you want.
[19:45] <lfaraone> neeraj: looking at the patch, it looks like you wrote it yourself.
[19:45] <dipankar> ebordon, but I would suggest you upgrade to ubuntu 10.04
[19:46] <neeraj> lfaraone: yes.  didn't know how to do otherway..
[19:46] <ebordon> dipankar: ok
[19:46] <lfaraone> neeraj: okay. so you adapted the patch from what was already shipped upstream in Sugar?
[19:47] <satellit_> ebordon: use another computer to make USB with startup Disk Creator /system/administration from booted CD choose USB
[19:48] <neeraj> lfaraone: yes. I have mentioned it in .patch file. We can always unapply the patch when we will update sugar via sugarlabs->debian->ubuntu. Can't we.
[19:48] <satellit_> (other computer has CD you can boot from)
[19:48] <neeraj> *?
[19:48] <ebordon> dipankar: I'm still downloading usr
[19:49] <satellit_> look at revised https://wiki.ubuntu.com/Sugar  for links
[19:49] <dipankar> ebordon, I was about to suggest what satellit_ told
[19:49] <dipankar> satellit_, thanks :)
[19:49] <lfaraone> neeraj: oh, right, hehe.
[19:49] <satellit_> yw
[19:50] <lfaraone> neeraj: /whois aleskey
[19:50] <lfaraone> (oops)
[19:50] <satellit_> dipankar: I revised that page today to reflect surf 115 and 804 USR links
[19:51] <dipankar> satellit_, thats wonderful! finally the page is revised with updates
[19:51] <ebordon> thanks satellit_
[19:51] <neeraj> lfaraone: ok. I should have used full name. Sorry for that. Re-submitting patch
[19:51] <satellit_> david said  it was ok to revise it
[19:51] <lfaraone> neeraj: no, hold on.
[19:51] <neeraj> lfaraone: ok
[19:52] <lfaraone> neeraj: since the patch wasn't written by you, rather than using your name in "From:", you probably should credit alsroot as the creator with "Author: Aleksey Lim<EMAIL_ADDRESS>[19:53] <lfaraone> neeraj: and rather than just providing a bug ## in the description, use "Bug: http://bugs.sugarlabs.org/path/to/the/bug/URL/on/our/tracker"
[19:54] <neeraj> lfaraone: ok :)
[19:54] <lfaraone> neeraj: and since it was cherrypicked, the "Forwarded" field isn't needed. (it'll be set to "yes" implictly if you include "Bug:")
[19:54] <lfaraone> neeraj: if you want extra bonus brownie points, include "Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/sugar-0.88/+bug/621896" as well.
[19:54] <ubot2> Launchpad bug 621896 in sugar-0.88 (Ubuntu) "Sugar emulator crashes while copying file from usb drive to journal (affects: 1) (heat: 6)" [Medium,New]
[19:55] <lfaraone> (in the patch header)
[20:01] <neeraj> lfaraone: ok. let me confirm. U want to me to add Bug-Ubuntu: (Link to mouse bug on LP) in .patch file. Right?
[20:02] <dipankar> alsroot, thanks for the pointers
[20:02] <dipankar> alsroot, I will get back to you after I understand them properly
[20:02] <lfaraone> neeraj: in addition to adding "Bug: (Link to the mouse bug on SL)".
[20:02] <neeraj> lfaraone: yes.
[20:03] <lfaraone> neeraj: yes.
[20:03] <neeraj> lfaraone: Can you please see if I missed anything this time. http://typewith.me/clJSy0SxkG
[20:05] <alsroot> dipankar: about gio, you can look into ASLO updater (updater control panel component), but it is only about downloading (but it should work similar for uploading)
[20:06] <satellitUSR-804> works  Ubuntu 10,04 LTS
[20:08] <dipankar> alsroot, ok. I thought gtk was related to window decoration.
[20:09] <dipankar> but gtk is widget programming
[20:10] <alsroot> dipankar: gtk does, but glib (underlying library and gobject itself) is more common library
[20:15] <dipankar> alsroot, gtk, glib and gio
[20:16] <dipankar> alsroot, thanks again for the pointers
[20:16] <dipankar> alsroot, see you tomorrow
[20:17]  * dipankar is off for the night
[20:57] <lfaraone> alsroot: so has sugarlabs bug #1544 been merged yet?
[20:57] <ubot2> Launchpad bug 1544 in launchpad-registry "Choosing a source package to link a product series should use a selection widget" [Low,Fix released] https://launchpad.net/bugs/1544
[20:57] <alsroot> lfaraone: nope
[20:58] <lfaraone> alsroot: seriously? it's been sitting in the tracker for 4 months.
[20:58] <lfaraone> alsroot: oh, it doesn't have r?...
[20:59]  * alsroot thinks better to wait a bit for 1y :)
[20:59]  * alsroot pings erokos
[21:00] <lfaraone> alsroot: heh. tomeu is listed as the bug owner.
[22:45] <lfaraone> neeraj: looks okay, althiugh I'd move the "Bug" fields higher above the free-form text,
[22:46] <lfaraone> neeraj: but I can do that manually.


[04:49] <pitti> Good morning
[06:01] <pitti> infinity: is there some amount of merges you would trade against taking initramfs-tools from me?
[06:03] <pitti> infinity: hm, it seems texinfo, apr, and vim are all comparatively simple
[07:05] <dholbach> good morning
[07:08] <dholbach> @pilot in
[07:24] <dholbach> cyphermox, what do you think about https://code.launchpad.net/~jbicha/ubuntu/saucy/network-manager/depend-on-valac/+merge/166626?
[07:25] <dholbach> to me it seems to be a bit of a matter of preference - I'll leave it up to you :)
[08:13] <infinity> pitti: Oh, I'll take initramfs-tools back anyway, since I'm upstream.  My bad for forgetting about it.
[08:14] <pitti> infinity: thanks; I'm happy to take off texinfo and apr from you anyway if you want
[08:15] <infinity> pitti: I have no great love for texinfo.  I should probably keep apr until I figure out a cleaner way to make crossing happy upstream.
[08:15] <infinity> pitti: Oh, actually, my texinfo cross hacks are vile too.  I should probably keep that and sort out something less disgusting.
[08:16] <infinity> pitti: I forgot that was the package I did *that* to.
[08:16]  * infinity finds his lunch returning upon re-reading that diff.
[08:17] <geser> sounds like forgetting as a good idea in this case :)
[08:36] <dholbach> Mirv, so I merged your touch merge proposal for ubuntu-seeds - are you going to upload another -meta?
[08:37] <dholbach> Mirv, there's a bunch of changes since the last time - does http://paste.ubuntu.com/5731925/ look all right to you?
[08:37] <dholbach> Mirv, I can put your email address into it if you like ;-)
[08:40] <Laney> you might want to check with ogra
[08:40] <Laney> "Removed powerd" seems suspicious
[08:40] <Laney> but maybe that's pulled in another way
[08:40] <ogra> erm, the touch seeds are special
[08:41] <dholbach> ogra, ok, so I just merged https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.add-qt-accounts-friends-plugins/+merge/166223 and did nothing else
[08:41] <Mirv> dholbach: thanks! looks good for the sdk related changes, although I can't do the uploads.
[08:41] <dholbach> I'll leave the rest to you then
[08:41] <ogra> you need to manually hack them until things are in the archives, germinate cant use PPAs
[08:41] <dholbach> aha
[08:41] <dholbach> nevermind then
[08:41] <cjwatson> mm, been meaning to figure that out ...
[08:41] <ogra> i'll take care later
[08:41] <dholbach> thanks ogra!
[08:41] <Mirv> (I haven't done any touch meta related changes)
[08:41] <ogra> cjwatson, nah, we better get that stuff into the archive
[08:42] <cjwatson> Well, sure, but I consider it a germinate bug anyway
[08:42] <cjwatson> Probably
[08:47] <infinity> germinate can't use PPAs?
[08:47] <infinity> Can't you just feed it another -m?
[08:48] <infinity> I would think that should Just Work.
[08:52] <cjwatson> Well, this is germinate-update-metapackage, so it all needs to go in update.cfg.  But apparently shoving in more archives didn't do the trick, and I haven't had a chance to investigate yet.
[08:53] <infinity> Yeah, I was just following that code now to see how or why that's more special than a by-hand invocation.
[08:53] <cjwatson> It does even go and fetch the relevant Packages files
[09:27]  * cjwatson attacks germinate-update-metapackage with pdb
[09:38] <cjwatson> ogra: So, wait.  Now that I've actually updated my seed checkout, I don't see anything wrong with germinate-update-metapackage's output.  What parts of http://paste.ubuntu.com/5732062/ do you think are wrong?
[09:39] <ogra> cjwatson, looks like it removed everything under the debug section ... weird
[09:39] <ogra> and powerd
[09:39] <ogra> though i'm not sure it is seeded
[09:39]  * ogra looks
[09:40] <cjwatson> ogra: "debug section"?
[09:40] <ogra> in the touch seed
[09:40] <cjwatson> ogra: It only removed powerd on i386
[09:40] <cjwatson> Where, I'm guessing, it doesn't exist
[09:40] <ogra> ah, that might be
[09:40] <cjwatson> ogra: All the entries in the debug section are duplicated from ubuntu-minimal
[09:40] <ogra> iputils-ping
[09:40] <ogra> from the debug section
[09:41] <ogra> oh
[09:41] <ogra> sorry, typed to fast
[09:41] <cjwatson> ogra: Your STRUCTURE file says "touch: minimal", so germinate intentionally prunes those
[09:41] <ogra> well, then it looks perfect
[09:41] <cjwatson> ogra: And, indeed, your livecd-rootfs config installs ubuntu-minimal as well, so they are indeed redundant
[09:41] <ogra> yeah
[09:42] <ogra> thats how it is supposed to be
[09:42] <ogra> i'll drop it from the seed
[09:42] <cjwatson> OK, I'll double-check powerd and if that's right then I'll upload
[09:43] <ogra> yeah, i think it is intentionally not built for x86 yet
[09:43] <ogra> iirc it wants to talk to android devices
[09:44] <cjwatson> Indeed, https://launchpad.net/%7Ephablet-team/+archive/ppa/+sourcepub/3241512/+listing-archive-extra concurs
[09:46] <cjwatson> That was against 1.009, BTW, so a bit laggy.  I'll update against 1.015
[09:58] <dholbach> @pilot out
[09:59] <dholbach> (I'll do the rest of my shift tomorrow. Got to take care of some other bits first.)
[10:15] <cjwatson> ogra: OK, uploaded ubuntu-touch-meta.  Could you use the ./update script for future changes?
[10:15] <ogra> cjwatson, with pleasure !
[10:15] <ogra> thanks a lot !
[10:15] <cjwatson> np.  didn't really do much other than observing it worked :-)
[12:23]  * cjwatson holds his breath and uploads a debhelper merge
[12:23] <cjwatson> Let me know if you notice any resulting weirdness
[12:35] <jibel> pitti, is there any limitation to upgrade udev/systemd in an lxc container ? upgrade from 202-0ubuntu12 to 204-0ubuntu1 hangs on configure
[12:38] <pitti> jibel: not known to me at least; can you please file a bug?
[12:39] <pitti> jibel: I tested the upgrade on a normal system, which went fine
[12:39] <jibel> pitti, sure, it's is blocked on "stop udev"
[12:39] <pitti> jibel: I guess I should be reproducible in otto? :-)
[12:40] <pitti> jibel: oh, it's the *old* udev which fails to stop?
[12:40] <jibel> pitti, yes, that's the problem :) I was provisioning a fresh saucy
[12:40] <pitti> postinst does "invoke-rc.d udev restart", that shoudl call "stop udev"
[13:10] <jibel> pitti, bug 1187375
[13:15] <pitti> jibel: thanks; I'll stop my "fix autopkgtest" vendetta now and look at this
[13:17] <jibel> pitti, thanks!
[13:25] <Riddell> stgraber: anything I should look out for in this user upstart kde-plasma session?  seems to work fine
[13:32] <stgraber> Riddell: with unity we had some problems around accessibility, input methods and some environment variables being missing. That last one should be fine for KDE as it's using a single upstart job and so that problem shouldn't be possible. Input methods and accessibility are probably worth checking though.
[13:40] <Riddell> gpg: problem with the agent - disabling agent use
[13:40] <Riddell> stgraber: might that be caused by it?
[13:40] <Riddell> ^^
[13:41] <pitti> jibel: indeed, booting today's iso in otto, "sudo stop udev" works, but "sudo start udev" hangs (that's with 202 only, no upgrade)
[13:44] <stgraber> Riddell: maybe, though we do ship a gpg-agent.conf upstart job that should avoid that. Does KDE ship its own gpg agent (similar to gnome-keyring in gnome)?
[13:46] <stgraber> Riddell: either way, "initctl status gpg-agent" and "env | grep GPG" may help figuring out what's going on there
[13:47] <stgraber> Riddell: oh, and "grep use-agent ~/.gnupg/gpg.conf" too
[13:47] <Riddell> >initctl status gpg-agent
[13:47] <Riddell> gpg-agent start/running
[13:47] <Riddell> GPG_AGENT_INFO=/tmp/gpg-cTlh4g/S.gpg-agent:24776:1
[13:48] <Riddell> use-agent is set in my ~/.gnupg/options
[13:48] <Riddell> and I have pinentry-qt4 installed
[13:48] <pitti> jibel: hm, I can manually stop and start udevd just fine, just the upstart command hangs; I wonder if it's somehow interfering with the host system
[13:50] <pitti> and ^Cing it and re-tryign "start udev" causes upstart to lie "job has already been started", although udevd isn't running
[13:52] <jibel> pitti, but upgrade from ubuntu11 to ubuntu12 went just fine on the same system. Shouldn't it have been affected as well is it was something with the host?
[14:09] <stgraber> Riddell: what do you get if you run "gpg-connect-agent"?
[14:11] <Riddell> stgraber: a > prompt character
[14:20] <stgraber> Riddell: ok, so it managed to connect to the agent...
[14:20] <stgraber> Riddell: that suggests the agent is running as expected, not sure what that error message is about then...
[14:21] <ogra> hmm, no infinity in #ubuntu-touch ... so i'll ask here ...
[14:21] <ogra> infinity, we need to find some way to exclude the /etc/init.d/ondemand script on ubuntu-touch
[14:22] <infinity> ogra: Why?
[14:22] <ogra> cpu frequency stuff is full in the hands of the android side
[14:22] <ogra> and my phone starts to glow after the script forced ondemand here
[14:23] <ogra> i was wondering if we could move it to its own package and just make it a recommends
[14:23] <infinity> interactive, surely.
[14:23] <infinity> If it's an Android kernel.
[14:23] <infinity> And all we're doing it poking some /proc bits, which I assume Android is setting similarly.
[14:23] <infinity> Can you see what all those bits are set to before ondemand runs?
[14:25] <infinity> ogra: Just how much Android userspace are we running, anyway?  And why don't we pare it down more?
[14:27] <pitti> jodh, xnox: if "sudo start udev" just hangs (in lxc), there is no udevd process, no log in /var/log/upstart, but I can manually start udevd just fine, how would I go to debug that?
[14:27] <ogra> well, over the years we might be able to pull over HW configs for each and every ubunt-touch port ... just not yet i guess
[14:28] <ogra> doing this part relibable in the same way android does it will be hard
[14:28] <ogra> and the android settings should usually get us the best setup for power saving
[14:28] <infinity> ogra: Eh?  What does this have to do with hardware configs?  If there's a frequency-twiddly daemon running, stop that.  Setting interactive should work fine.
[14:28] <jodh> pitti: looks like udevd has a --debug option - you could try adding that to /etc/init/udev.conf to see if you get any output.
[14:29] <infinity> ogra: Assuming the Android setup is what we want is probably not true.  Our userspaces are wildly different.
[14:29] <pitti> jodh, xnox: oh, of course -- just after I asked i got it
[14:30] <pitti> jodh, xnox: there was a "start on starting udev" job which failed; where would/should I have seen that?
[14:30] <pitti> jibel: ^ we need to auto-destruct or fix /etc/init/lxc-udev.conf :)
[14:30] <ogra> infinity, right, and currently our userspace doesnt have anything HW related at all we talk to HW through the platform-api
[14:31] <jodh> pitti: boot with --debug or "initctl log-priority debug" and check dmesg/syslog, or look at the /var/log/upstart/ log if the failing job produced any output.
[14:31] <pitti> jodh: there was no /var/log/upstart/udev.log; I guess it didn't even get to that yet, as it tried the depending lxc-udev.conf first
[14:31] <pitti> jodh: ah, thanks for "log-priority debug"
[14:33] <infinity> ogra: Yes, but we don't need to "talk" to anything WRT frequency scaling.  It's set-and-forget in the kernel, unless there's a daemon running that does weird things.
[14:33] <infinity> ogra: And if there is, I don't see how we're getting in its way.
[14:34] <ogra> no, it isnt ... that was long ago
[14:34] <ogra> with interactive governors the user actions are monitored all the time
[14:34] <infinity> By the kernel.
[14:34] <infinity> Hence my "set and forget" comment.
[14:35] <infinity> This is true of all governors except powersave and performance.
[14:35] <ogra> well, the interactive governor on the nx4 has like 20 settings or so
[14:35] <ogra> and they differ for every exynos
[14:36] <ogra> s/exynos/exynos device/
[14:36] <infinity> ogra: Instead of trying to outsmart the kernel and set fiddly bits (like you did in the upload after mine), you could just let the defaults get used.
[14:37] <ogra> not with ubuntu-touch ... the defaults are set from androids init
[14:37] <ogra> so we need to leave it to the container to set them up
[14:37] <ogra> and not force ondemand
[14:38] <infinity> We don't force ondemand.
[14:38] <jibel> pitti, Oh, I see the problem. I'll create an override on first run. Why does it fail now and in previous upgrade?
[14:38] <jibel> pitti, thanks for finding this
[14:38] <infinity> ogra: What order do these scripts get run in?  Ours first, then Android's, or the inverse?
[14:39] <infinity> ogra: And what do the settings look like when Android's done with it?
[14:39] <pitti> jibel: I'm working on a fix
[14:40] <infinity> ogra: I contend that if we remove all those little hacks and tweaks from your 2.88dsf-13.10ubuntu15 upload, it'll all work fine.
[14:40] <pitti> jodh: hm, I did the initctl log-priority, but I still don't see anything at all in dmesg and /var/log/syslog when I do "sudo start udev"
[14:40] <infinity> ogra: Cause if Android's setting up tweaks, and all we're doing is setting it to interactive, everyone wins.
[14:40] <jodh> pitti: did you "sudo initctl log-priority"? If not, you'll just have changed the log priority for your session init if this is saucy ;)
[14:40] <ogra> infinity, we force ondemand if we do find it
[14:41] <ogra> (and the system uses one of its own governors nobody knows about ... like on three of my foud devices here)(
[14:41] <ogra> *four
[14:41] <infinity> ogra: No, we force ondemand if we *don't* have interactive.
[14:41] <ogra> yes
[14:42] <infinity> ogra: So, what are these other governors?
[14:42] <pitti> jodh: yes, it's today's saucy image, and I ran it with sudo
[14:42] <ogra> inevnted by the vendors
[14:42] <infinity> ogra: Their names. :P
[14:42]  * ogra doesnt have the names here
[14:42] <ogra> not std kernel ones
[14:43] <infinity> ogra: Sure, interactive isn't standard either.
[14:43] <ogra> hmm, i thought it was since a while
[14:43] <ogra> on arm at least
[14:43] <infinity> No, it's Android-specific.
[14:43] <jodh> pitti: confused then. try starting/stopping another job and seeing if you get output. Presumably "logger foo" does the expected on that system?
[14:44] <ogra> well, in any case, android will set them on container start
[14:44] <pitti> jodh: sudo stop/start whoopsie also doesn't log anything; logger foo works
[14:45] <pitti> jodh: might be because that's inside a container?
[14:45] <infinity> ogra: Sure.  So, we can make our script just exit silently if it finds any of these other fancy governors.
[14:45] <ogra> so we are setting them twice ... with the non flipped container pretty harmfulk *after* android comes up ... with the flipped one we just have a redundant call before the android container sets it again
[14:45] <jodh> pitti: maybe rsyslog isn't running?
[14:45] <jodh> pitti: unsure - stgraber?
[14:45] <infinity> ogra: And I'm not sure flipping matters, given that the init script sleeps for 60s, it's probably always run last.
[14:45] <ogra> infinity, i would at least make it fail if it finds the android upstart job
[14:46] <ogra> oh, right
[14:46] <pitti> jodh: it is running, I get log messages from other stuff just fine (e. g. dbus tells me spawned services)
[14:46] <ogra> still redundant though
[14:46] <infinity> ogra: What's this Android upstart job?  We can certainly just exit 0 if that exists.
[14:47] <ogra> lxc-android-container.conf
[14:47] <jodh> pitti: hmm - I'm actually getting the expected output to the console on my raring lxc container. Maybe boot with 'lxc-start -L /tmp/console.log' or similar?
[14:47] <ogra> if it wouldnt be a sysvinit script that would be easier :)
[14:48] <pitti> ls -l /var/lib/lxc/
[14:48] <pitti> argh
[14:49] <pitti> jodh: anyway, I have a job "start on starting udev and started mounted-run" "task" "script" "true" "end script" (i. e. doing nothing); that completely blocks "start udev"
[14:49] <infinity> ogra: Out of curiosity, where did all these interactive tweaks come from?
[14:50] <ogra> infinity, the ones we ship atm ?
[14:50] <ogra> androids nexus7 init scripts
[14:50] <pitti> jodh: I guess it doesn't consider lxc-udev (that job) as started (status lxc-udev says "unknown job"), so I guess that wait condition is busted somehow?
[14:50] <infinity> ogra: Ahh.  Kay.  I'll just tear them out, I think, since I can't imagine they're ideal for any interactive-using device, and kernel defaults seemed good enough.
[14:51] <ogra> infinity, loading interactive with its defaults made the device crawl
[14:51] <ogra> yeah, tear themm out
[14:51] <ogra> nexus7 desktop is done
[14:51] <infinity> ogra: That's the opposite of the reports I got from others when I enabled it...
[14:51] <ogra> the load was constantly around 2.x
[14:51] <ogra> with interactive properly configured it was normal
[14:52] <ogra> feel free to try it if you still have an nx7 desktop around :)
[14:52] <infinity> I don't.
[14:52] <ogra> it was a quite noticeable difference
[14:52] <ogra> (like switching from beagle to panda)
[14:55] <jodh> pitti: suggests the mounted-run job isn't running which will indeed block any follow-on jobs. Try booting with "lxc-start -L /tmp/console.log -- /sbin/init --debug" and looking in /tmp/console.log for the mounted-run job.
[14:55] <jodh> pitti: you could also create a job that specifies "start on mounted\n exec env \n", boot and check the log again to see which mounted events you are actually getting.
[14:55] <pitti> jibel: ^ can I pass this option to lxc-start from otto start?
[14:56] <pitti> jodh: right, mounted-run is a signal, not a job
[14:56] <pitti> jodh: it'll only happen on boot AFAIK (it works there, i. e. during bootup udev is getting started just fine)
[14:56] <pitti> jodh: ok, I'll probably just redesign that job to disable itself
[14:57] <jodh> pitti: mounted-run is a job.
[14:57] <jibel> pitti, if it is supported by the python binding yes
[14:58] <infinity> ogra: http://paste.ubuntu.com/5732832/ <-- Verify that path is right?
[14:59] <ogra> infinity, wrong ... /etc/init/lxc-android-config.conf
[15:00] <infinity> 08:47 < ogra> lxc-android-container.conf
[15:00] <infinity> 08:59 < ogra> infinity, wrong ... /etc/init/lxc-android-config.conf
[15:00] <infinity> This is what I get for trusting people. ;)
[15:00] <ogra> haha, sorry
[15:01] <pitti> jodh: ah, close enough; it's a task, i. e. it's usually stopped
[15:01] <infinity> ogra: Uploaded with that correction.
[15:01] <pitti> jibel: I have the upstart job create an .override file now, but that's broken if we keep deltas -- you can't ever boot this container twice then
[15:02] <pitti> jibel: so I'd rather not use anythign file system based, except /run
[15:02] <pitti> do we have a /run/init/ for jobs?
[15:03] <ogra> infinity, thx !
[15:03] <pitti> jibel: ah, easier I think: udev starts on "virtual-filesystems", which sounds like including /run; so I don't think we need to repeat that condition in lxc-udev; I'll just drop it
[15:03] <xnox> pitti: i don't think we do. but we could add it, e.g. upstart does support multiple locations in priority order correctly.
[15:04] <xnox> (as used in user sessions for example)
[15:04] <stgraber> xnox: didn't we explicitly decide not to support this in system mode?
[15:04] <pitti> jibel: ok, that works fine
[15:04] <jibel> pitti, otherwise we could delete the override in the pre-mount
[15:04] <jibel> pitti, ok
[15:04] <pitti> stgraber: it would be similar to /run/udev/rules.d/
[15:05] <xnox> stgraber: correct. but it wouldn't be hard to enable.
[15:06] <stgraber> xnox: sure, it's just that in a recent MP we agreed this would likely be confusing and cause some weirdness if one of the paths doesn't exist. That's why jodh made a change to allow the option be passed multiple times but discard all but the last instance (and added matching tests to ensure that doesn't change)
[15:10] <xnox> stgraber: thinking about it yeah... it might be weird. does mountall mount /run or is it mounted in initramfs?! it would be confusing not to have conf-source on boot, as we might fail to start tracking it with inotify.
[15:10] <xnox> and initctl reload-configuration would be needed.
[15:11] <stgraber> xnox: /run is usually mounted by the initramfs, so that's fine (so long as you have one), but we'd still hit that kind of problem if you were to pass a /var directory or something under /usr
[15:11] <xnox> sure.
[15:12] <cjwatson> ah, phablet-flash is still looking at ubuntu-touch-preview - if I want to try the ubuntu-touch (saucy) images do I need to do that by hand somehow?
[15:15] <xnox> cjwatson: yes. https://wiki.ubuntu.com/Touch/Install#Manual_Installation
[15:15] <xnox> using the matching/correct saucy files. push first one, reboot into recovery, push second one, reboot into recovery again and you should be good to go.
[15:16] <cjwatson> k, thanks
[15:17] <cjwatson> I got my hopes up when I saw stuff in the changelog about pulling from cdimage, but of course that was ubuntu-touch-preview
[15:21] <pitti> jibel: hm, seems we need the "mounted-run" after all, so I don't commit my changes
[15:21] <pitti> jibel: so we need to remove the override in the pre-mount script
[15:21] <pitti> jibel: I'll commit that
[15:22] <pitti> jibel: (done)
[15:25] <jibel> pitti, many thanks, I'll do a run with the fix.
[15:39] <pitti> slangasek: err -- how come that I was just about to do a test build/upload of binutils to fix exactly the same issue that you did 5 mins ago? :-)
[15:39] <pitti> slangasek: thanks
[15:42]  * pitti goes on to the next one
[15:47] <pitti> slangasek: do we still need the "Breaks: libiodbc2" in odbcinst1debian2 (from bug 901638)?
[15:48] <pitti> slangasek: I'm looking at the psqlodbc autopkgtest which doesn't work in ubuntu as one cannot install its dependencies due to that
[15:48] <Laney> xnox: are those saucy images supposed to work currently?
[15:48] <Laney> I just pushed them and I got into a reboot loop
[15:50] <xnox> Laney: I had more success upgrading and/or using the custom saucy image from someone's blog post.
[15:50] <Laney> I think I'll go back to the normal ones for now
[15:50]  * Laney fablet-phlash
[15:50] <pitti> slangasek: it was an upgrade fix to precise, but I'm not sure whether it still makes sense semantically
[15:52] <Laney> wait, might have pushed the wrong thing the second time
[16:03] <ev> bdrung: hi. Are you still unable to access errors.ubuntu.com?
[16:04] <ev> we've had another report of this today via dpm, so this could be a bug
[16:04] <pitti> barry: hey, how are you?
[16:05] <barry> pitti: hi!  good, and you?
[16:05] <pitti> barry: are you interested in fixing oneconf's autopkgtest? it outputs a lot to stderr (which could be a redirection), but several tests fail, too
[16:05] <pitti> barry: I'm fine, thanks!
[16:06] <barry> pitti: i could take a crack at it, but it probably won't be today.  is there a bug open on it?
[16:06] <pitti> barry: I can open one if it helps for scheduling/reminding
[16:06] <barry> pitti: it definitely would :)
[16:07] <pitti> barry: nah, doesn't need to be today, I'm just trawling through our stack of failures, fixing some (mostly the debian imports), and nagging some people to fix "theirs"
[16:07] <pitti> barry: cheers, will do
[16:07] <barry> pitti: sounds good
[16:10] <infinity> pitti: Does eglibc still fail?  I haven't looked in a while.
[16:10] <infinity> pitti: Interestingly, after we went and blamed qemu/kvm, eglibc passed its testsuite with flying colors on the new kvm openstack buildds.
[16:10] <infinity> pitti: And it's not the raring/saucy kernels, cause that's what I test on at home.
[16:10] <pitti> infinity: hah, good to hear
[16:10] <infinity> pitti: So, if it's still broken, I'm a bit stumped.
[16:11] <pitti> barry: filed bug 1187460 with all links and an excerpt of the failures
[16:11] <infinity> pitti: And I really don't want to go randomly disabling tests because the autopkgtest rig is less reliable than the buildds, that would be moving in the wrong direction.
[16:11] <pitti> yes, it still fails
[16:11]  * pitti downloads the 57 MB log
[16:11] <cjwatson> You could selectively disable them in autopkgtest if you were really stuck
[16:12] <cjwatson> (env variable, filtering, whatever)
[16:12] <pitti> infinity: the host that we are running this on is probably still precise
[16:12] <infinity> cjwatson: I could slap in a different set of expected results, yeah.  But ew.
[16:12] <barry> pitti: thanks
[16:12] <infinity> pitti: precise host and saucy guests, I assume?
[16:13] <pitti> infinity: saucy guest definitively (we use the daily servercloud image); let me double-check the host
[16:13] <cjwatson> pitti: Ha, I fixed the haskell-yesod one in darcs just before I saw the IRC notification of your bug
[16:13] <infinity> pitti: I don't see how that would be any weirder than any of the setups where it's all gone fine, but I dunno.
[16:13] <pitti> cjwatson: oh, awesome!
[16:13] <infinity> pitti: Anyhow, I need a bit of a nap, so I'll have to ponder it a bit later.
[16:14] <cjwatson> Ah, apparently not quite, hadn't realised yesod was genuinely exiting non-zero too
[16:14] <pitti> badpkg: dependency install failed, exit code 2
[16:14] <pitti> cjwatson: ah, "yesod test" exiting with 127 is actually expected?
[16:15] <cjwatson> I don't think so
[16:15] <cjwatson> I'll look
[16:15] <pitti> infinity: so it's something else now; let's look tomorrow, it's getting late for me, too
[16:15] <infinity> pitti: Oh yay for "something else". :)
[16:15]  * pitti crosses fingers that binutils will succeed now
[16:16] <pitti> infinity: /usr/lib/pbuilder/pbuilder-satisfydepends-classic fails now
[16:16] <pitti> i. e. some bad or uninstallable dependencies
[16:16] <infinity> pitti: Curious.
[16:16] <pitti> Passed regression testing. No new failures, no changed error values.
[16:16] <pitti> infinity: ^ that bit looks good, though :)
[16:17] <infinity> pitti: Shiny.
[16:17] <infinity> pitti: So, apparently, ignoring failures is the best way to fix them.
[16:18] <pitti> oh wait, I think that might not be the whole story
[16:18] <infinity> pitti: Where can I find this log again?  Jenkins and I don't love each other.
[16:19] <pitti> infinity: http://paste.ubuntu.com/5733066/ is the "interesting" excerpt
[16:20] <pitti> infinity: does that look like a test pass or fail? (not sure whether these "make check" errors are expected)
[16:20] <pitti> infinity: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-eglibc/17/ARCH=amd64,label=adt/
[16:20] <infinity> pitti: That's a pass.
[16:20] <pitti> infinity: "log" is the full log
[16:20] <infinity> pitti: It prints out the output of the XFAILs just to remind you. :P
[16:20] <pitti> infinity: ok, then it's just some bogus with test depends or something; I'll have a look tomorrow
[16:21] <infinity> pitti: Well, locales-all doesn't exist.
[16:22] <infinity> pitti: Probably my fault for allowing it to be in the .dsc
[16:22] <pitti> ah, was just trying this with apt-get, indeed
[16:23] <pitti> infinity: we could just add a "Depends: libc-dev" to debian/tests/control
[16:23] <pitti> infinity: the default is "Depends: @" which means "all binaries from that source"
[16:23] <pitti> infinity: but as the important part is the "needs-build", and the actual test is just a "true", the Depends: doesn't matter and it can be a dummy
[16:24] <pitti> infinity: so "libc-dev" or "coreutils" or something like that should do fine
[16:24] <infinity> pitti: Ahh, that would do.
[16:25] <pitti> infinity: do we have a Vcs-* on the Ubuntu side to commit that?
[16:25] <pitti> might not be worth an upload just for this
[16:25] <infinity> pitti: I'll commit it to Debian, the test lives there.
[16:25] <pitti> ah, great; just to stow it away and not having to remember all this again next time
[16:26] <infinity> pitti: I'll just do "Depends: build-essential", seems appropriate for a needs-build.
[16:26] <pitti> infinity: yep, that's what we have in binutils
[16:27] <pitti> (although it's also just a dummy, Depends: is installed after building, FYI)
[16:28] <infinity> pitti: *nod*
[16:28] <infinity> pitti: Is there a bug for this?
[16:28] <pitti> infinity: I can create one if you want to
[16:28] <infinity> Nah, I'm good.
[16:29] <cjwatson> pitti: ah, yesod is just a missing test dep
[16:30] <pitti> cjwatson: oh, is it? I was running this in a VM, and the "yesod" command seemed to exist
[16:30] <cjwatson> it needs cabal-install too
[16:30] <cjwatson> after that it's fine
[16:30] <pitti> ah, nice
[16:30] <cjwatson> (was clear-ish from strace)
[16:30]  * infinity really naps now.
[16:32] <pitti> now, after the efforts of the last three days, let's see how long it takes until the failures are a screenful again :)
[16:33] <pitti> this should get quite a bit better with britney integration in the future, though
[16:33] <pitti> jibel: OOI, any news about the RT about sending the notifications to the uploader?
[16:38] <jibel> pitti, yes, I received an update this morning, and IS is setting up a relay for the lab and "it should be ready in the next couple of days"
[16:38] <pitti> jibel: nice
[16:40] <seb128> pitti, hey, do you plan to deal with the packagekit transition? seems it's in proposed since over a month and that you uploaded it?
[16:40] <Laney> jbicha was talking about that earlier
[16:40] <pitti> seb128: oh sorry, I wasn't aware it's stuck in -proposed
[16:41] <pitti> seb128: yes, can do tomorrow
[16:41] <seb128> pitti, it's not going to be a "tomorrow" thing afaik, we didn't do the transition last cycle because abis changed quite a lot and aptdaemon and stuff need to be ported
[16:41] <seb128> pitti, but we should probably start organizing that (or revert the update)
[16:41] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "valid candidate", hmm
[16:42] <seb128> skipped: packagekit (35 <- 26)
[16:42] <seb128>     got: 172+0: i-172
[16:42] <seb128> with a load of packages
[16:42] <slangasek> pitti: binutils> great minds? ;)
[16:42] <pitti> seb128: yes, there is bug 1175972 at least
[16:42] <seb128> pitti, see https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1022407
[16:42] <seb128> pitti, do you think that update is worth the work involved?
[16:43] <seb128> pitti, I'm pondering if we should just revert to the old version...
[16:43] <Laney> they're not all direct depends
[16:43] <slangasek> pitti: the libiodbc2 breaks can be made Breaks: libiodbc2 (<< 3.52.7-3).  Why does psqlodbc reference iodbc, though?  It should only be using unixodbc
[16:43] <pitti> seb128: I don't have a strong opinion yet before looking at how much needs porting
[16:43] <seb128> Laney, right, but I though we didn't go for it in raring because porting aptdaemon and stuff is not trivial
[16:43] <cjwatson> pitti: update_excuses is package-local checks, update_output is global checks
[16:43] <seb128> pitti, right, we should have a look at the work involved
[16:43] <cjwatson> pitti: (as in Debian)
[16:44] <pitti> slangasek: it's a test dependency, debian/tests/isql has tests for both unixodbc and iodbc
[16:44] <pitti> slangasek: so if we cannot make them co-installable, we can split the test or disable the iodbc one
[16:45] <cjwatson> Reverting to the old version isn't a "just", since it has the potential to screw up library dependencies, surely
[16:45] <pitti> slangasek: but versioned breaks sounds great
[16:45] <slangasek> pitti: disable the iodbc test, iodbc is irrelevant
[16:45] <cjwatson> (I think the pressure to decide whether to revert quickly is off, FWIW, given that this is only in -proposed; yes, I realise it impedes development in the medium term but it's not breaking users so we have some time)
[16:45] <slangasek> pitti: we don't need two ODBC DMs, and the only reason I haven't shot iodbc in the head in Debian is because the Debian KDE folks refuse to let it die
[16:46] <pitti> slangasek: ack, thanks
[16:47] <seb128> cjwatson, right, it's not a "just", but I'm not wanting to spend efforts in porting/fixing aptdaemon/software-center etc for no benefit out of being on the current upstream version of packagekit, at least not this cycle where we have been asked to focus efforts on phone and other things
[16:47] <pitti> seb128: urgh, that's a sizable stack indeed
[16:47] <pitti> seb128: so, I have no particular urgency with the new PK
[16:47] <seb128> pitti, we stayed away from it for a reason...
[16:47] <pitti> it's not even supported
[16:47] <cjwatson> ask somebody like glatzor if he can help, maybe?
[16:48] <seb128> pitti, did you want the new one for a reason or did you overlook that the abi changed so much?
[16:48] <seb128> cjwatson, https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1022407/comments/6
[16:48] <pitti> cjwatson: yes, I was talking to him quickly about porting aptdaemon
[16:48] <seb128> cjwatson, he said he would work on it, but it has been over 6 months
[16:48] <seb128> cjwatson, I'm sure that will happen at some point, but he seems quite busy atm
[16:48] <Laney> might as well ask
[16:49] <Laney> the transition is pretty well advanced in saucy-proposed as far as archive reverse dependencies go
[16:49] <seb128> glatzor, ^
[16:49] <cjwatson> or Matthias Klumpp might be willing to help out with aptdaemon, perhaps?
[16:49] <pitti> seb128: I wasn't aware it changed so much; I thought some rebuilds would do; but I didn't really spend that much time on it TBH
[16:49] <seb128> ok
[16:49] <pitti> cjwatson: I doubt that, given that Matthias heavily advocates to drop aptdaemon and move to PK proper
[16:49] <seb128> is Matthias Klumpp on IRC?
[16:50] <cjwatson> incidentally, if you do get to the point where you decide the best option is to revert, please talk to me first; it may well be better to simply remove the affected packages from -proposed than to upload a mangled-version thing
[16:50] <pitti> seb128: ximion AFAIR
[16:50] <seb128> pitti, thanks
[16:50] <seb128> cjwatson, noted
[16:50] <seb128> we will wait to hear back from glatzor
[16:50] <seb128> we for sure don't have anyone in Desktop with the free slots to do non trivial aptdaemon porting this cycle
[16:51] <cjwatson> or some combination of removals and rebuilds-against-old-library, or similar.  Just thought I'd say because mangled versions are hard to undo later
[16:51] <Laney> I might manually block it then
[16:51] <Laney> since AFAICT it's in danger of transitioning when stuff builds
[16:51] <cjwatson> If stuff builds then we're golden, surely
[16:51] <pitti> doing it now sounds like lots of pain for little gain then, as long as it's still in Debian experimental
[16:51] <seb128> are stuff likely to build if they are not ported?
[16:51] <Laney> I thought the problem was in python-aptdaemon
[16:52] <seb128> they also changed the dbus apis I guess?
[16:52] <Laney> (or whatever the exact package name is)
[16:52] <pitti> but I didn't expect the API to change that much really; my feeling is that it's mostly aptdaemon
[16:52] <cjwatson> I'd have thought aptdaemon's build-time tests would fail
[16:52] <pitti> they do
[16:52] <pitti> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-aptdaemon/
[16:52] <pitti> they fail in the PK compat bits
[16:52] <Laney> it's not an rdep of the C library though
[16:52] <seb128> pitti, if you see bug #1022407 (which has the NEWS entry), it says "We've broken a lot of API in this release. A LOT"
[16:53] <seb128> Laney, yes, please put a manual blocker on it
[16:53] <cjwatson> ah, aptdaemon isn't in the broken list
[16:53] <cjwatson> so yeah, agree with seb128
[16:53] <Laney> right, so britney isn't helping out
[16:53] <Laney> doing
[16:53] <seb128> Laney, thanks
[16:53] <seb128> do we need an archive grep for the users of the dbus api if that changed?
[16:54] <pitti> we should do that, yes (start with codesearch.d.n?)
[16:55] <Laney> sounds good
[16:55] <pitti> but most stuff really ought to use the library or the gir, not talk to dbus
[16:55] <pitti> (aside from the fact that the d-bus API is really hard to use)
[16:56] <seb128> pitti, right, I guess the main user is aptdaemon which implements the same apis
[16:58] <seb128> Laney, pitti: http://codesearch.debian.net/search?q=org.freedesktop.PackageKit lists stuff like libreoffice and nautilus using directly the dbus api
[16:59] <seb128> g-c-c yelp
[16:59] <Laney> I'm guessing a lot of stuff will be ported based on the comment in the bug
[17:01] <cjwatson> Do autopkgtests have network access?
[17:01] <cjwatson> Guess it's better not to rely on it ...
[17:04] <jbicha> g-c-c should be fine since 3.6; I believe we actually disable yelp's PK integration since aptdaemon didn't support that feature
[17:04] <seb128> g-c-c is not fine no
[17:04] <pitti> cjwatson: through a proxy, but not very reliably indeed
[17:04] <seb128> jbicha, it's broken the other way around, https://git.gnome.org/browse/gnome-control-center/commit/?id=5366d1188e212d472905ac325df9a4c03eb711a9 ... it will turn off the feature at runtime
[17:05] <seb128> jbicha, which probably means the current archive version has that feature broken :/
[17:06] <jbicha> it's not a very useful feature since we have a dedicated app for checking & installing updates
[17:08] <seb128> right
[17:10] <Laney> I found https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-package-kit
[17:10] <Laney> which links a branch to port aptdaemon but it would likely need more work
[17:11] <Laney> I guess we can revisit in a little while as long as things aren't blocked on it
[17:11]  * Laney goes away
[17:12] <seb128> Laney, right, thanks, have fun
[17:13] <seb128> Laney, yeah, that vcs didn't have any commit for 8 months
[17:23] <pitti> seb128: so tomorrow, should we review how many rebuilds in -proposed we'd need when we drop 0.8 from -proposed?
[17:23]  * pitti needs to make dinner now and has a meeting at 8, can't spend much time on that any more today, sorry
[17:23] <seb128> pitti, I would still like to have an estimate of the aptdaemon port work and a reply from glatzor
[17:24] <seb128> pitti, no worry, we will not sort it out today
[17:24] <seb128> pitti, enjoy your evening, let's look to it a bit more tomorrow
[19:12] <dobey> what's the expected TTL to go from proposed to release pocket on saucy at the moment?
[19:17] <stgraber> dobey: should still be a week for saucy-proposed => saucy-updates, assuming that all the bugs have been verified
[19:20] <seb128> stgraber, ?
[19:21] <stgraber> seb128: ?
[19:21] <seb128> stgraber, saucy is the current active serie, why would proposed to archive take a week?
[19:22] <stgraber> seb128: oops, brain not working today ;) I parsed that as raring...
[19:22] <seb128> dobey, should take a publisher run (less than an hour)
[19:22] <stgraber> dobey: so the real answer is 30min if it's not stuck because it's braking the world
[19:22] <stgraber> *breaking even
[19:22] <seb128> stgraber, ;-)
[19:23] <dobey> oh
[19:24] <seb128> dobey, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt to see if it's blocked by a transition or something
[19:24] <stgraber> dobey: if you give me the name of the source I can tell you why it's stuck?
[19:24] <seb128> dobey, what source are you looking at?
[19:25] <dobey> ubuntu-sso-client. i guess it's blocked due to the breaks/replaces on python-ubuntuone-storageprotocol i added
[19:26] <seb128> dobey,     * i386: deja-dup-backend-ubuntuone, gir1.2-syncdaemon-1.0, libsyncdaemon-1.0-1, libsyncdaemon-1.0-dev, magicicada, python-ubuntuone-control-panel, ubuntuone-client, ubuntuone-client-gnome, ubuntuone-client-proxy, ubuntuone-control-panel, ubuntuone-control-panel-qt
[19:26] <stgraber> dobey: yep, looks like it'll prevent a whole bunch of packages from being installable, so britney refuses to promote it
[19:33] <dobey> right, ok.
[19:36] <arges> hallyn: hi. Is the qemu-kvm_1.0 package based on the qemu-kvm.git repo tagged qemu-kvm-1.0? or is from another source/tag? thanks
[19:42] <doko> infinity, did you sync llvm-toolchain-3.2? looks like not all patches were migrated from llvm-3.2
[19:56] <slangasek> pitti: hmm, I don't understand why jenkins still shows the binutils autopkgtest as failed, because when I drill down I see "no failures" on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-binutils/12/
[20:11] <hallyn> arges: yes, qemu-kvm.git
[20:15] <arges> hallyn: thanks
[20:30] <slangasek> cjwatson_: if parted fails with a given GPT, but the kernel and gdisk are both happy with it, is this worth a bug report on parted?
[20:30] <slangasek> cjwatson_: http://paste.ubuntu.com/5733851/
[20:37] <dobey> any archive admin around that can take care of bug #1187554 real quick?
[20:42] <ev> kees: can you try logging in to errors.ubuntu.com for me?
[20:42] <ev> I think we've fixed it
[20:46] <kees> ev: sure, one sec
[20:46] <ev> cheers
[20:47] <kees> ev: hm, same thing
[20:47] <ev> damn
[20:48] <slangasek> dobey: yes - though why the urgency?
[20:49] <ev> oh, my mistake
[20:50] <ev> fixing
[20:51] <dobey> slangasek: not really urgent. just want to see it gone :)
[20:51] <slangasek> dobey: ok, well, done then; but removals are normally batch-processed
[20:51] <ev> kees: if you could try once more, I'd appreciate it
[20:53] <dobey> slangasek: thanks
[20:53] <cjwatson_> slangasek: yep
[20:54] <slangasek> cjwatson: ok.  What data should I attach?
[20:54] <cjwatson> dd of the relevant chunks of disk
[20:55] <slangasek> cjwatson: can you hint me which bits are "relevant"? :)
[20:55] <cjwatson> first 4KB should do
[20:55] <cjwatson> at a guess
[20:55] <slangasek> ok
[20:55] <cjwatson> (IIRC it's actually in sector 1)
[20:55] <cjwatson> Make it 16KiB just in case it has a funny block size or something
[20:58] <slangasek> cjwatson: bug #1187560
[21:21] <kees> ev: sure, one sec
[21:22] <kees> ev: yay! works.
[21:23] <ev> woohoo!
[21:23] <kees> ev: so, is it possible to search based on apport fields?
[21:24] <ev> kees: can you give me an example, or otherwise elaborate on the use case?
[21:24] <ev> the short answer is no, but perhaps it's something we should be doing :)
[21:26] <kees> ev: for example: all packages that crashed with 'Signal' == 11
[21:27] <kees> or, better, all package that have 'SegvReason' containing the string 'executing writable'
[21:29] <ev> there's a few things we could do here
[21:30] <ev> the easiest would be to start tracking the type of crash at the problem level (group of instances of errors matched with the same signature) and keep an index of these
[21:30]  * tedg__ thinks it's nice that kees is making "big data" rootkits  ;-)
[21:30] <kees> generally being able to fish out specific apport fields would be great, but for me personally, I'd like to see the SegvReason and likely things like ProcMaps, Disassembly, and Registers
[21:30] <ev> for the latter case of doing text based searches, we have Hadoop coming this cycle
[21:31] <ev> hopefully
[21:31] <kees> tedg__: yeah, I used to mine launchpad for this stuff. it's great
[21:31] <ev> making a note of all this to explore it in more detail tomorrow and see if we can't come up with a plan
[21:31] <kees> ev: cool, thanks. in the meantime, I'll continue to poke around.
[21:31] <ev> kees: let me know if you break anything ;)
[21:32] <kees> ev: sure thing :)
[21:32] <tedg__> kees, That would be a great defcon talk: "Using Big Data for Evil"  ;-)
[21:33] <ev> tedg__: surely this is adorable-sized data compared to the stuff Google is running :)
[21:33] <tedg__> ev, yes, but Google's not allowed to be evil ;-)
[21:34] <kees> tedg__: I proposed that. they didn't take me up on it. :)
[21:34] <kees> ev: are kernel crashes being reported into this too?
[21:34] <ev> it's quite hard to be when you have a quiet room filled with teddy bears
[21:34] <ev> kees: yes, but it's forever on my list to figure out why we're not getting any
[21:35]  * tedg__ imagines that defcon just rejects all talks and expects you to hack the database and change your talk to accepted if you really want it.
[21:35] <thegatta_> hahaha it could work
[21:36] <sarnold> kees: what?!? You said, "hey guys, wouldn't it be more fun if we _could_ be evil?" and they said _no_??
[21:36] <tedg__> ev, Hmm, now you've left me wondering whether teddy bears are cheaper than sound foam for my office.
[21:37] <ev> tedg__: it'd surely make the property tax inspector give you a good rate
[21:38] <ev> right! I'm getting out of here before you lot create any more work for me
[21:38] <tedg__> 'night ev!
[21:38] <ev> if you desperately want any more features while I'm sleeping, lp:errors is place to go ;)
[21:38] <ev> night!
[21:40] <kees> sarnold: hah, no defcon rejected it
[21:40] <kees> ev: cya!
[21:40] <tedg__> kees, I'm kinda curious if we could track segfaults on system services along with geoip based data to discover botnets looking for vulnerable systems.
[21:40] <sarnold> kees: ah. :)
[21:40] <tedg__> kees, Unfortunately we don't have apport on by default in server.
[21:40] <sarnold> tedg__: ooo
[21:41] <kees> ev: btw, getting kernel crashes showing up would be more interesting than the apport fields for me, if you want to priority on those requests. :)
[21:41] <kees> tedg__: heh. too bad!
[21:41] <kees> it's safe to do suidcoredump=2 thing now, too.
[21:42] <kees> er, fs.suid_dumpable=2  rather
[21:43] <kees> that was a fun fix, inspired by some discussion with ev a while back...
[21:45] <bdrung> ev: no. i can access errors.ubuntu.com again.
[23:04] <xnox> slangasek: can we please have your libpam-runtime back?! =) I believe it's so much better. bug 1187579
[23:05] <slangasek> xnox: hmm, you mean libpam-xdg-support?
[23:05] <xnox> yes.
[23:05] <slangasek> preferably not :)
[23:06] <xnox> slangasek: thanks for volunteering to fix the above bug =) did you notice similar? or shall I wait to see what pitti thinks about it =)
[23:06] <slangasek> yes, pam_xdg_support uses a simpler method of managing sessions, but
[23:06] <slangasek> xnox: I haven't upgraded to 204-0ubuntu1 yet
[23:06] <xnox> hm. ok.
[23:06] <slangasek> I think the person who uploaded it should get to fix this ;P
[23:06] <xnox> solomon's decision - invoke the TIL rule
[23:58] <infinity> doko: I didn't, no.


[02:20] <wallyworld> axw: sorry, finger slipped :-)
[02:20] <axw> wallyworld: bye :p
[04:13]  * thumper is done
[04:14] <thumper> laters
[09:02] <dooferlad> dimitern: hangout?
[09:03] <voidspace> dimitern: http://reviews.vapour.ws/r/1970/
[10:38] <dimitern> TheMue, LGTM
[10:43] <TheMue> dimitern: thx
[10:44] <voidspace> dooferlad: thanks
[11:48] <voidspace> dooferlad: failing tests, so I'll have to investigate and resubmit
[11:48] <voidspace> dooferlad: on my branch (thought I'd run the tests - but obviously not)
[11:53] <dimitern> voidspace, TheMue, dooferlad, guys, I'm not feeling well and need to get some rest, so I might be back later in the evening
[11:53] <TheMue> dimitern: oh, hope you'll get well soon
[11:54] <dimitern> thanks
[13:00] <rogpeppe> anyone know how to bootstrap a local provider without apt-get installing juju-local
[13:00] <rogpeppe> ?
[13:00] <rogpeppe> i really don't want to have juju-local installed because i never ever want to use /usr/bin/juju
[13:01] <rogpeppe> fwereade: ^ ?
[13:01] <fwereade> rogpeppe, afraid not
[13:01] <fwereade> rogpeppe, I don't mind having a /usr/bin/juju hanging around :)
[13:01] <rogpeppe> fwereade: problem is, i can remove /usr/bin/juju but it keeps on *coming back*
[13:02] <rogpeppe> fwereade: i like being able to do go install juju/... and then running "juju". it always surprises me when it chooses /usr/bin/juju
[13:02] <mgz> rogpeppe: curtis has a fake juju-local package
[13:02] <mgz> that you can install, plus the real deps of juju-local
[13:02] <rogpeppe> mgz: ha, that would be great (although, wtf!)
[13:03] <rogpeppe> ISTM that juju should check for the actual deps it needs, not juju-local per se
[13:03] <fwereade> rogpeppe, to be fair it's not optimal: I do have a mild `ll $(which juju)` habit
[13:03] <rogpeppe> mgz: know where i can get it from?
[13:04] <mgz> trying to find it again
[13:04] <rogpeppe> mgz: ta
[13:05] <mgz> rogpeppe: forwarded you mail
[13:05] <rogpeppe> mgz: thanks!
[13:06] <mgz> I presume it still works, is a hack from a year ago
[13:06]  * rogpeppe tries to remember how to install debs directly
[13:06] <mgz> dpkg -i
[13:07] <rogpeppe> ah dpkg
[13:07] <rogpeppe> i should do it more often
[13:11] <rogpeppe> mgz: thanks, that worked nicewly
[13:11] <rogpeppe> nicely, even
[13:11] <mup> Bug #1464356 changed: TestCloudInit fails <blocker> <ci> <regression> <test-failure> <juju-core:Invalid> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1464356>
[13:16] <tasdomas> hi
[13:16] <tasdomas> soulc somebody take a look at http://reviews.vapour.ws/r/1116/ and tell me if it's a bad idea?
[13:17] <mgz> is dimitern off today?
[13:17] <mgz> if so, probably want someone else to fix the 1.24 branch
[13:18] <tasdomas> s/soulc/could
[13:18] <mgz> see bug 1464356
[13:18] <mup> Bug #1464356: TestCloudInit fails <blocker> <ci> <regression> <test-failure> <juju-core:Invalid> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1464356>
[14:00] <natefinch> ug, why the heck does juju/errors/NewErr return a value that does not satisfy the error interface? :/
[14:01] <perrito666> natefinch: because satisfying the interface is too mainstream
[14:02] <natefinch> perrito666: It just means that you can't use that function to directly embed the value into another error type... which is the only reason that function even exists.
[14:03] <katco> natefinch: standup
[14:03] <katco> wwitzel3: not sure if you're here yet, but standup if you are
[14:05] <natefinch> katco: coming'
[15:05] <pmatulis> hello, re restrictions (block/unblock), does an unblock override a restriction set in environments.yaml ?
[15:54] <fwereade> is anyone who worked on status-history aroound?
[15:55] <perrito666> fwereade: I am
[15:56] <fwereade> perrito666, so, we seem to do things quite strangely there
[15:56] <perrito666> tell me
[15:56] <fwereade> perrito666, ISTM that we destroy history before we're finished with it
[15:56] <fwereade> perrito666, and that unit.Destroy now runs 2 transactions in flagrant violantion of sense or sanity
[15:57] <perrito666> fwereade: mmm, destruction of history  was one of the things that I was unsure of
[15:57] <perrito666> fwereade: wanna hangout?
[15:58] <fwereade> perrito666, sure, start one
[15:59] <perrito666> fwereade: come to https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand it is a deserted land at this time of the day
[15:59] <fwereade> perrito666, by which I mean "please, good sir, would you be so kind as to start a hangout and invite me to join it" :)
[16:24] <mup> Bug #1466269 changed: bootstrap instance started but did not change to Deployed <bootstrap> <maas> <windows> <juju-core:New> <https://launchpad.net/bugs/1466269>
[17:32] <natefinch> ericsnow, katco:  I'm not going to be able to get this landed before I get back, which will be in approximately 2 hours.  Sorry, the rebase caused some conflicts, and I evidently did the wrong thing when merging them (i.e. I had removed plugin.go from the process dir in my branch, and it looks like more was added to that file in eric's branch).
[17:32] <ericsnow> natefinch: if you don't mind, I can take a stab at getting it merged...
[17:33] <katco> ericsnow: natefinch: we can wait since our planning meeting is on mon
[17:33] <ericsnow> katco, natefinch: k
[17:33] <natefinch> ericsnow: you're welcome to.
[17:33] <katco> natefinch: but we do need that landed today i think
[17:33] <natefinch> katco: yep
[17:34] <natefinch> katco:  it's a matter of putting back the plugin.go file and removing the launch details struct from it, I believe.
[17:34] <natefinch> ericsnow: ^
[17:34] <ericsnow> natefinch: if it can wait it will probably be better for you to sort it out
[17:34] <natefinch> ericsnow: that's fine
[17:34] <natefinch> I should have time
[17:34] <natefinch> gotta run
[17:34] <ericsnow> natefinch: also, considering merging rather than rebasing
[17:35] <ericsnow> natefinch: take care
[18:03] <mup> Bug #1466951 opened: juju no-proxy does not work with apt-http-proxy <juju-core:New> <https://launchpad.net/bugs/1466951>
[19:06] <moqq> i have the machine-0 jujud agent consuming our entire cpu on both of our environments, independantly
[19:06] <moqq> has anyone here seen this before?
[19:06] <mup> Bug #1466969 opened: Upgrading 1.20.14 -> 1.24.0 fails <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1466969>
[19:09] <perrito666> moqq: not me, is there any logging that we can see?
[19:10] <moqq> after startup everything appears idle from the logs, strace reveals its spending a lot of time on futex
[19:10] <moqq> i can grab the startup logs one sec
[19:11] <moqq> mongo also is spiking a lot with it
[19:11] <perrito666> moqq: juju version?
[19:11] <moqq> less consistently, but there seems to be a lot of activity between them
[19:12] <moqq> 1.23.3-trusty-amd64
[19:22] <moqq> perrito666: https://gist.github.com/tysonmalchow/765ed773a7edfc0a2f96 is the startup log
[19:23] <perrito666> moqq: weird, I see nothing out of the ordniary :(
[19:27] <moqq> :(
[19:28] <moqq> i really dont want ot have to scrap juju 1 month after getting it into our production env… but unless i can fix this we’re going to have to :(
[19:29] <perrito666> moqq: sadly it is friday afternoon so not many people around to help either, if you can hold it is very likely that more of us around could solve your issue
[19:30] <moqq> okay well that’s comforting to hear
[19:31] <perrito666> moqq: though the last link they passed in #juju seems relevant
[19:32] <moqq> yeah i’ve tried as many permutations of the advice on that thread as possible to no avail so far
[19:48] <natefinch> ericsnow: doing the fixup now.  I noticed your LaunchDetails validate method errored if status is empty.... do we really want to error in that case?  Seems like ID should be required, but status is just a nice to have.
[19:50] <ericsnow> natefinch: one key motivation for this feature is to display the current status of a managed workload process, so I'm leaning toward always requiring it
[19:51] <natefinch> ericsnow: fair enough
[19:55] <natefinch> ericsnow: so, thinking about this some more.. it's somewhat problematic.  We've told the plugin to launch a process, and presumably it has.  It has returned an ID, but no status.... returning an error from Launch would probably make the rest of the system think that no process was launched, even though one was.  I'm worried that'll leave people in a weird state.
[19:55] <natefinch> ericsnow: I guess the error from launch would cause whatever hook is firing to go into an error state... which might be good enough, since it should only happen at dev time
[19:56] <natefinch> (hopefully)
[20:00] <ericsnow> natefinch: that sounds right
[20:01] <fwereade> yay, I got the most totalitarian rb id yet
[20:01] <fwereade> http://reviews.vapour.ws/r/1984/
[20:04] <perrito666> fwereade: loooool
[20:05] <natefinch> fwereade: double plus good
[20:06] <mup> Bug #1466984 opened: juju cannot remove-machine even with --force <juju-core:New> <https://launchpad.net/bugs/1466984>
[20:07] <perrito666> means we had at least that amount of reviews in a year
[20:07] <natefinch> perrito666: less than a year, really
[20:07] <perrito666> less?
[20:07] <perrito666> mm true, was around july right?
[20:08] <natefinch> perrito666: something like that... I forget exactly when it went live.. .august even, I thought
[20:08] <natefinch> perrito666: I dunno, it took ericsnow forever to get that thing deployed ;)
[20:08] <perrito666> I do recall we showcased it in the induction sprint for ericsnow and katco
[20:08] <ericsnow> natefinch: :)
[20:09] <perrito666> and at that point it was near the 4th of july because we had this very cool trip to boston with many patriotic things going on
[20:09] <katco> perrito666: ericsnow: we decided to move to RB at my induction sprint. implementation was that winter.
[20:09] <katco> perrito666: ericsnow: sometime between oct.-dec.
[20:09] <mup> Bug #1466984 changed: juju cannot remove-machine even with --force <juju-core:New> <https://launchpad.net/bugs/1466984>
[20:11] <ericsnow> katco, perrito666: first one (mid-September): http://reviews.vapour.ws/r/18/
[20:12] <mup> Bug #1466984 opened: juju cannot remove-machine even with --force <juju-core:New> <https://launchpad.net/bugs/1466984>
[20:15] <natefinch> ericsnow: what do you think about the proc-register command needing to pass the same format as launch returns?  i.e. id and status both in a json blob?
[20:15] <natefinch> ericsnow: would let us reuse more code and keeps the API consistent
[20:15] <ericsnow> natefinch: makes sense
[21:01] <natefinch> ericsnow, katco:  I'm going to have to finish up this merge tonight.... there's just a ton of places where we're using the old process.LaunchDetails that need to be modified to use plugin.ProcDetails.
[21:01] <ericsnow> natefinch: k
[21:01] <natefinch> also ericsnow - env_test.go:80: envSuite.TestUnparseEnvOkay    - this is relying on map ordering... you need to use jc.SameContents
[21:01] <katco> natefinch: k please make sure it gets done
[21:01] <ericsnow> natefinch: k
[21:01] <natefinch> katco: I will.  Sorry, been busting my butt, but there was a lot more to the merge than I had hoped.
[21:02] <natefinch> katco: I have a couple more hours of work time to get it done tonight and I think I'n really close right now.
[21:02] <natefinch> katco: just gott arun for dinner.. natives are restles
[23:16] <mup> Bug #1466984 changed: juju cannot remove-machine even with --force <juju-core:New> <https://launchpad.net/bugs/1466984>


[12:19] <sharpertool> Good morning channel
[12:44] <nael_n> What's the difference between #ubuntu-gnome and #ubuntu-desktop?