[00:10] <infinity> shadeslayer: It's a compiler, it needs porting/bootstrapping.
[05:24] <pitti> Good morning
[05:24] <pitti> Good morning
[06:26] <RAOF> pitti: Good morning.
[06:27] <pitti> hey RAOF, how are you?
[06:27] <RAOF> pitti: Is there any particular reason why umockdev_testbed_add_from_{string,file}() don't return the sysfs path like umockdev_testbed_add_device does?
[06:27] <RAOF> pitti: I'm pretty rad.
[06:27] <pitti> RAOF: well, *which* sysfs string?
[06:27] <pitti> a file usually contains a lot of devices
[06:27] <RAOF> Oh, yeah. Multiple devices in there.
[06:27] <RAOF> Question answered!
[06:28] <pitti> I thought about that, but if you only have a single device then add_from_* isn't really more useful than a simple add_device()
[06:46] <RAOF_> pitti: What do you think of adding the device node used to record the ioctls to the umockdev ioctl dump? Then your dump could create the device and populate the ioctls without manual futzing.
[06:46] <pitti> RAOF_: so, like a merged .umockdev and .ioctl format?
[06:47] <RAOF_> pitti: Either that or enough info in the .ioctl that it can be matched up with the umockdev on load.
[06:47] <pitti> RAOF_: I'd like to at least keep the possibility of separate formats as that's useful (you may want to change device properties or the device names, but keep the ioctls; or load different ioctls/scripts for the same devices, etc.)
[06:47] <pitti> and their formats are quite different
[06:48] <pitti> RAOF: so asked the other way around, how should that look like in pseudo-code from your POV?
[06:49] <RAOF> From the API point of view, or internal?
[06:49] <pitti> from API, i. e. for you as a user
[06:49] <pitti> right now, you load the devices from .umockdev
[06:49] <pitti> and then assign a script or an ioctl dump to a particular device
[06:49] <pitti> (or several)
[06:50] <RAOF> umockdev_testbed_add_from_file(foo.umockdev); umockdev_testbed_load_ioctl(foo.ioctl); where foo.ioctl was generated at the same time as foo.umockdev
[06:50] <pitti> ah, so keep the files separate
[06:50] <pitti> RAOF: so with load_ioctl(foo.ioctl, NULL) it could look up the original file
[06:51] <RAOF> Yah.
[06:51] <pitti> or with (foo.ioctl, "/dev/bus/usb/...") an arbitrary one
[06:51] <RAOF> Yeah.
[06:51] <pitti> RAOF: ok, so the script and ioctl formats have room for this kind of extension, and that wouldn't break API/ABI
[06:51]  * RAOF isn't entirely sure why you'd want to play the ioctl from an arbitrary devnode, but you probably have a better grasp of the usecases.
[06:52] <pitti> RAOF: well, in my tests (shotwell etc.) I usually don't want to change the test device nodes when I refresh or change the ioctl dump
[06:52] <pitti> RAOF: but when I re-do ioctls, the device numbers are usually entirely different than at the time of the previous recording
[06:52] <RAOF> Ah, ok. See! Usecase :)
[06:52] <pitti> and often tests use devices like /dev/bus/usb/my_cam
[06:53] <pitti> which are easier to follow in  logs, etc.
[06:53] <RAOF> Yeah, that seems reasonable.
[06:54] <pitti> RAOF: so yes, I think a NULL argument seems possible at first sight; mind filing an issue for this?
[06:54] <RAOF> pitti: Sure
[07:04] <RAOF> pitti: Enjoy: https://github.com/martinpitt/umockdev/issues/33
[07:12] <pitti> RAOF: heh, thanks
[07:27] <comander> hello there
[07:27] <comander> i want help regarding Qt i want get the output of a process that i evoked via my Qt app
[07:29] <comander> via QProcess and want to get output  either in QtextEdit widget or something else that could do same
[09:53] <zyga> Hi. My package got MIR-ed into main but now it is back in universe. Can anyone help me figure out why did that happen? https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1265754/comments/4
[10:07] <pitti> zyga: there's nothing to hold it in main
[10:08] <pitti> zyga: you need to add it as a dependency of something in main, or seed it
[10:08] <pitti> zyga: otherwise it'll be in component-mismatches and re-demoted quickly
[10:12] <mlankhorst> do I need to file a MIR for some xorg-server 1.15 dependencies too?
[10:12] <zyga> pitti: thanks for confirming that, it was our suspiction all along
[10:12] <jpds> Surely you should file a MIR for mir?
[10:13] <zyga> pitti: will it be automatically re-promoted once that dependency shows up?
[10:13] <zyga> pitti: (it will shortly)
[10:13] <pitti> zyga: yes; please set back the MIR bug to "Fix committed", so that the archive admins can find it
[10:13] <zyga> pitti: thanks
[10:18] <Unit193> jpds: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1203207
[10:20] <zyga> MIR MIR MIR ;)
[10:31] <cjwatson> slangasek: yes, grub-install was rewritten upstream - it was getting beyond the bounds of what was sane to do in shell.  I thought I'd seen reports suggested that shim was being installed OK though.  The output of "grub-install -v" may be helpful - it should provide a reasonable trace of what grub-install is doing
[11:36] <smoser> xnox, around >
[11:36] <smoser> ?
[11:36] <xnox> smoser: yeah, what's up?
[11:36] <smoser> i'm looking at overlayroot and interaction with cryptsetup
[11:36] <smoser> i'd *like* cryptsetup to always get the modules it needs.
[11:37] <smoser> but faliing that, what can I / should I do
[11:37] <xnox> set $CRYPTSETUP=y
[11:38] <xnox> smoser: in /etc/initramfs-tools/initramfs.conf or otherwise when cryptroot-hook is executed.
[11:39] <smoser> xnox, but i can't really update that.
[11:39] <smoser> from one package, updating another package config.
[11:39] <xnox> smoser: true.
[11:40] <xnox> smoser: or i'll upload "CRYPTSETUP=y in cryptsetup package if e.g. a cloud-initramfs hook exists.
[11:41] <smoser> xnox, ?
[11:41] <xnox> smoser:  where is overlayroot hook?
[11:41] <smoser> theres an overlayroot hook
[11:41] <smoser> cloud-intiramfs-tools
[11:41] <smoser> but if you can change the default (which you previously un-set) is good with me.
[11:41] <xnox> ev: Unable to locate package cloud-intiramfs-tools
[11:42] <xnox> ev: Unable to find a source package for cloud-intiramfs-tools
[11:42] <xnox> is it in trusty?
[11:42] <smoser> cloud-initramfs-tools
[11:42] <smoser> no package
[11:42] <smoser> overlayroot is the package
[11:42] <smoser> cloud-initramfs-tools is source
[11:42] <xnox> got it.
[11:49] <smoser> xnox, so you're just going to turn CRYPTSETUP=y on ?
[11:50] <xnox> smoser: yes, but only for overlayroot, not by default everywhere.
[11:50] <smoser> how?
[11:50] <smoser> i dont follow.
[11:50] <smoser> i dont know how you'd do that
[11:50] <xnox> smoser: i'm experimenting atm.
[11:51] <smoser> k. feel free to quote bug 1267225
[11:51] <smoser> (ie, in the change log as the fix)
[12:20] <xnox> smoser: /usr/share/initramfs-tools/conf-hooks.d/ is exactly where we should be able to set CRYPTSETUP=y, but when testing locally cryptroot is not executed / sourced at all so modules are not getting added.
[12:21] <xnox> smoser: testing wubi at the moment, and will test this in a pristine machine next.
[12:27] <smoser> xnox, i dont think it works like that
[12:27] <smoser> all hooks don't work in a global environment
[12:27] <smoser> that just wouldnt work.
[12:28] <xnox> smoser: that's exactly how cryptsetup pulls in busybox & framebuffer (plymouth)
[12:32] <smoser> thta just seems like a namespace nightmare
[12:35] <soren> smoser: Actually, hooks are sourced, not executed.
[12:35] <soren> smoser: So they do share environment namespace.
[12:37] <ogra_> does cloud-initramfs-tools provide its own hook ? if so, just adding cryptsetup to the PREREQ var should work
[12:38] <ogra_> (though that will indeed always pull it in)
[12:39] <xnox> ogra_: true! thanks.
[13:44] <mlankhorst> any MIR member on?
[14:06] <jodh>  /go touch
[14:07] <ogra_> yeah, there are some go apps on touch :)
[14:16] <jodh> ogra_: :)
[14:49] <smoser> xnox, did you test ogra_'s suggestion?
[15:00] <bcurtiswx> mthaddon, did you want to work on the site issues at all today?
[15:06] <mthaddon> bcurtiswx: I've spoken to the web team and they've suggested how I might be able to update the theme (needs a bit of manual work though) so I'll try to get to that today or tomorrow and let you know how I get on
[15:07] <bcurtiswx> mthaddon, great, much thanks. If you want me at all i'll idle in our loco channel.
[15:07] <mthaddon> thx muchly
[15:15] <dobey> kenvandine_, robru: friends plug-ins are still all python right?
[15:15] <kenvandine_> dobey, yup
[15:15] <robru> dobey, yessir!
[15:17] <dobey> kenvandine_, robru: is there a good example for doing read-only?
[15:17] <robru> dobey, flickr / foursquare I think are simpler ones
[15:18] <robru> dobey, probably flickr. it's slightly bitrotted at the moment, but the principles are sound
[15:18] <dobey> ok
[15:18] <robru> dobey, (like, it bitrotted against flickr's api. it demonstrates friends plugin api just fine)
[15:18] <dobey> right
[15:23] <mpt> cyphermox_, <https://wiki.ubuntu.com/Networking#captive-portal> and <https://wiki.ubuntu.com/Networking#settings-connections>
[15:39] <roadmr> dholbach: hello! hey brendand was asking you some things about checkbox. To be more specific, checkbox (the source package) would sprout two new binaries, and one of the old ones (checkbox-qt) would likely turn into a dummy, transitional package. Is this allowed?
[15:40] <dholbach> roadmr, yes
[15:41] <roadmr> dholbach: awesome! \o/ thanks. One of the binaries is just moving some python modules off into a new package to make them reusable, so there's no huge change in size or functionality
[15:41] <dholbach> roadmr, excellent
[15:42] <roadmr> dholbach: thanks so much :)
[16:02] <caribou> infinity: remember the makedumpfile merge, I may not be able to get the mods pushed into Debian before the debian sync freeze
[16:02] <infinity> caribou: Was it just packaging changes you needed to push, or also a new upstream?
[16:02] <infinity> caribou: And why not?  I can sponsor it for you, as I said.
[16:03] <caribou> infinity: it's closing the delta b/w debian & ubuntu so they are the same
[16:03] <caribou> infinity: I still need my sponsor to merge the changes into our master branch
[16:04] <caribou> infinity: if not, we can merge the current code, it's minimal
[16:05] <caribou> infinity: the difference is only the Arch in debian/control
[16:05] <infinity> caribou: Alright, well.  I can merge with Debian for now, and then any packaging changes you make in Debian later, we can easily sync back.
[16:05] <caribou> infinity: oh, I did the merge work, I'll only need sponsorship for the upload
[16:05] <infinity> caribou: Or that.  Sure.
[16:06] <infinity> caribou: You have a pointer to the source package?
[16:06] <caribou> infinity: ok, I'll ping you for that once I'm done with the merge bug with the debdiff
[17:17] <seb128> Riddell, hey, any news from calligra?
[17:17] <seb128> Riddell, if not, can we just go with a no change rebuild from the previous version?
[17:17] <seb128> that's blocking libreoffice 4.2 and other stuff to migrate (poppler transition)
[17:19] <Riddell> seb128: just finishing up now
[17:19] <seb128> Riddell, thanks
[17:20] <Laney> \o/
[17:21] <robert_ancell> seiflotfy__, can you add ps-jenkins to ~activity-log-manager so we can add CI?
[17:28] <hallyn> hi - i'm trying to get a single source for debian+ubuntu qemu.  i need a different series file in the ubuntu case.  is there a decent way in 3.0 (quilt) to handle this?  (I'm told I can no longer manipulate this at patch: or build-stamp: time)
[17:35] <Riddell> seb128: uploaded, fingers crossed
[17:35] <seb128> Riddell, thanks
[17:40] <ogra_> whee, thanks xnox for thinking of touch !
[17:43] <ogra_> (saw ubuntu-touch-session)
[17:45] <xnox> ogra_: remember, we test things before uploading ;-)
[17:45] <ogra_> some actually do :)
[17:50] <seb128> mardy_, hey, do you know what e-d-s files from /usr/lib/evolution-data-server/registry-modules are needed for uoa support?
[17:56] <hallyn> infinity: hi, looks like seabios (1.7.4-1) has autosynced and is in trusty-propsoed.  can we, uh, kill it with fire for now?
[17:56] <hallyn> infinity: the debian maintainer warns it'll break xen fro us
[17:57] <smb> (because of xen xl using standard qemu which uses seabios)
[17:58] <infinity> hallyn: It was FTBFS anyway, how much more killing with fire does it need?
[17:58] <smb> infinity, disintegrate
[17:58] <infinity> Oh, it wouldn't be FTBFS if someone retried it, looks like.
[17:59] <infinity> So, we can file a bug to prevent it from migrating for now.
[17:59] <hallyn> infinity: where/how do we file that?
[17:59] <infinity> Is there a Debian bug reference for this?
[17:59] <infinity> Or an Ubuntu one?
[17:59] <smb> infinity, We could not think of how. Basically remove it from archive existence and prevent it from ever auto-merging for now
[17:59] <hallyn> not yet
[18:00] <hallyn> smb: where 'fro now' is until after 14.04
[18:00] <hallyn> oh, bugs.debian.org/707454
[18:00] <cjwatson> hallyn: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-October/001068.html
[18:02] <infinity> hallyn: So, file a bug detailing *why* it's broken, and add the tag "block-proposed" to it.
[18:02] <infinity> cjwatson: Oh, you beat me to it while I was finding the tag. :P
[18:03] <infinity> hallyn: Erm, the way I read that bug, it's iasl that's the problem, not seabios.
[18:04] <infinity> hallyn: As in, a rebuild of seabios (even in the "okay" version) would break.  That's unacceptable.
[18:04] <infinity> hallyn: So, we should roll back iasl, probably.
[18:04] <infinity> hallyn: Unless something else needs the newer version.  Then we should fix seabios.
[18:04] <infinity> hallyn: Having the current combination of broken iasl and seabios that will break if rebuilt is a ticking time-bomb.
[18:04] <smb> infinity, http://paste.ubuntu.com/6874200/
[18:05] <smb> hallyn, Saving you the repeat...
[18:05] <cjwatson> xnox: I think I've fixed guile-1.8, in case that's been on your list
[18:05] <cjwatson> just test-building on ppc64el now to double-check
[18:05] <infinity> smb: Oh, hrm, that doesn't seem to relate to the bug hallyn pointed out.
[18:06] <infinity> 17:41 < mjt> only new qemu (from git) will try to load the 256kb version
[18:06] <infinity> hallyn: ^-- Can't we pull that patch into our qemu?
[18:06] <infinity> hallyn: That seems more future-proof than shipping an LTS that can't load the bigger BIOS files.
[18:07] <hallyn> infinity: I'm nto sure the patch exists yet (checking)
[18:08] <smb> infinity, I think he said later that qemu-2.0 will not be ready until April
[18:09] <hallyn> i don't see a patch in qemu to address this
[18:09] <hallyn> anyway if it is prefereable to let seabios continue to autosync and fix qemu if/when seabios builds and breaks xen-qemu, then i'm ok with that
[18:10] <smb> infinity, Also it may add some "interesting times" for people migrating guests from older to newer guests... if that is possible ...
[18:10] <hallyn> smb: an alternative would be to once again split off a xen-qemu :)
[18:10] <hallyn> right
[18:10] <smb> hallyn, bah
[18:10] <infinity> smb: If that's true, it'll be true some day anyway, no point putting it off.
[18:11] <smb> infinity, Yeah, thats a point
[18:11] <infinity> Anyhow, I'd imagine the qemu fix to allow fatter BIOSes will be small, targetted, and easy to cherry-pick, once someone finds it.
[18:12] <hallyn> optimist
[18:12] <infinity> It makes little sense, to me, to hold off on that migration until post-LTS, and ship an LTS that can't load bigger BIOSes (which people developing ON Ubuntu might want to do).
[18:12] <hallyn> ok, wont' file that bug then - thanks :)
[18:12] <infinity> That said, this seems entirely unrelated to the iasl/seabios FTBFS bug that hallyn pointed at, which would need to be addressed before you have a big BIOS to worry about anyway. :P
[18:13] <infinity> (And should be addressed regardless, since unbuildable packages in the archive are bad)
[18:13]  * smb will be expecting the sky to fall down any day then :-P
[18:17] <hallyn> infinity: yeah it looks like that's being worked
[19:25] <Noskcaj> Could someone please review lp:~noskcaj/+junk/gnome-weather ? This package needs to be added for ubuntu-gnome
[19:26] <Noskcaj> It cannot be uploaded via debian due to use of the CC-BY-2.0 license
[19:50] <wget> Hi guys. On Ubuntu and derivatives, I noticed that the symbols defined at /proc/kallsyms are all zeroed when read as a standard user, but are the right location when read from root. Do you have applied a patch for that.
[19:50] <wget> I checked with distributions and even compiled a kernel by myself and noticed all the symbols (or most of them) are readable by a standard user on these distributions.
[19:50] <wget> You have thus enabled some extra to hide these symbols, noh?
[19:55] <mwhudson> is there anyone around who is prepared to admit to understanding the libv8 packaging?
[19:57] <dobey> wget: #ubuntu-kernel would be the place to ask that i think
[19:58] <wget> dobey: :-( ok thanks, think I'm lost these days...
[21:19] <xnox> mwhudson: i don't think anyone will admit that =) but what's your actual question about it? =)
[21:26] <dobey> kenvandine: does friends-service integrate with messaging indicator, or is friends-app required for that?
[21:27] <kenvandine> dobey, it doesn't
[21:27] <kenvandine> either could
[21:28] <dobey> kenvandine: ah, it would be great if it did. i'm writing a github plug-in. it would be great if the messages indicator could show counts for comments/pull requests/etc…
[21:29] <kenvandine> dobey, it would be great :)
[21:31] <dobey> kenvandine: also, do you know if it's possible to tweak the display name for an online account after logging in with oauth2, in the gtk+ UI? the google qml plug-in has code that sets it, but that isn't used in the gtk+ ui. the vala google accounts plug-in doesn't do the same thing though
[21:32] <kenvandine> i thought it did in the gtk one
[21:32] <dobey> not that i can see from looking at the code
[21:37] <kenvandine> dobey, maybe that was something magically done with signon-ui... i don't recall
[21:37] <mwhudson> xnox: i'd like to build a libv8 package from a much newer upstream
[21:37] <mwhudson> i think
[21:38] <dobey> kenvandine: yeah i don't know. i don't want to add a google account either, because it does a million things i don't want and screws with evolution and such :)
[21:39] <xnox> mwhudson: and the one in the archive is not using gyp yet, yet new upstream only support gyp based buildsystem?
[21:39] <mwhudson> xnox: no, the one in the archive uses gyp i think
[21:40] <mwhudson> xnox: i guess i don't understand git-buildpackage, maybe
[21:44] <xnox> mwhudson: well, take new source code, copy across debian/ do "./debian/rules build"
[21:44] <xnox> does that work?
[21:45] <mwhudson> let's find out, i guess
[21:46] <mwhudson> well that's going to build a libv8-3.14.5 that contains libv8 3.24.whatever
[21:46] <mwhudson> which doesn't seem ideal
[21:50] <Noskcaj> infinity, PING
[21:51] <Noskcaj> I've just merged the new cogl release, could you test build it on ppc64el since the patch might be fixed. https://code.launchpad.net/~noskcaj/ubuntu/trusty/cogl/1.16.2/+merge/204787
[21:51] <Noskcaj> powerpcel is now in the libtool.m4 and the patch doesn't apply
[22:04] <mwhudson> uh, all this machinery does not appear to support building a libv8-3.24.31 package
[22:04] <infinity> mwhudson: Renaming some files and munging debian/control isn't enough?
[22:05] <mwhudson> infinity: well sure, but i had gotten the impression that the control munging was automated
[22:05] <mwhudson> seems not though
[22:05] <infinity> Automated control munging is usually not a sane idea, to be fair.
[22:06] <infinity> Noskcaj: If the new upstream contains the bits from my patch, there's no need to test it.
[22:06] <mwhudson> oh huh, the only difference between debian/control.in and debian/control is build-depends
[22:06] <Noskcaj> infinity, It only says powerpcle rather than powerpc64el, plus i'd rather be sure
[22:07] <infinity> Noskcaj: Erm.  Look closer?
[22:08] <infinity> Noskcaj: Pretty much exactly this should show up in the new upstream: http://launchpadlibrarian.net/160371627/cogl_1.14.0-3_1.14.0-3ubuntu1.diff.gz
[22:08] <infinity> Noskcaj: Where's the new upstream tarball?  Looking at the your MP diff is pretty close to useless.
[22:10] <Noskcaj> https://download.gnome.org/sources/cogl/1.16/cogl-1.16.2.tar.xz
[22:22] <mhall119> cjwatson: slangasek: so we've all more of less decided on naming SDK releases after ubuntu releases, so the next one won't be SDK 2.0, it'll be SDK Ubuntu 14.04
[22:22] <mhall119> does that sound reasonable to you both?
[23:37] <eagles0513875> hey guys I have a question is the arm port of 14.04 also supporting 32bit arm procs?
[23:49] <infinity> eagles0513875: Yes.  "armhf" is 32-bit (armv7, hard-float)
[23:50] <eagles0513875> infinity: ok :) thanks for the info :) need to do some research into this for a project of mine :)