[02:18] pitti: Hrm. Check out the sbcl failure in utopic-proposed. pkgstrip vomits with a "find : permission denied"... Bug in pkg* for not ignoring that, or bug in sbcl for producing non-readable/traversable files/directories during build, or both? [02:32] pitti: (Testing the obvious fix for sbcl and will submit that to Debian regardless, but wondering if we should also consider this a pkgbinarymangler failure and fix that) [02:48] camako: oh, sure, can do! [02:48] Good morning (or so) [02:49] infinity: yes, in general I think we should fix this stuff in pkgbinarymangler too, to avoid rather pointless package deltas [02:52] camako: I wasn't aware that you guys are waiting on this, so thanks for the ping [04:10] camako: released upstream 0.8.7 and uploaded to sid; I'll sync it in a few hours once it got imported into LP [05:30] attente_: it's released yesterday, I'm working on it atm [06:56] I'm one of the upstream devs of librdf-trine-perl, and I've just committed some rather extensive performance enhancements in the package. These are the only changes since the last version, which is already in utopic === BruceMa is now known as BM === BM is now known as BMW === BMW is now known as BM2 [06:56] we would normally not be releasing a new version with just a single changeset, but if it could make it into Utopic, we might do it anyway [06:57] so, I was wondering if it is worth releasing and pestering the Debian dev about it, or if it is too late anyway? === BM2 is now known as BruceMa [07:01] KjetilK: We're (way) past feature freeze, so unless you can make a good case for why it's absolutely necessary for utopic, it probably wouldn't make it anyway. [07:01] infinity, yeah, I figured [07:01] KjetilK: But releasing and getting it into Debian for jessie (and we'll pull it into 15.04) still isn't a bad plan. [07:02] yeah, the DD usually packages our releases in a week or two [07:03] KjetilK: Right, well the jessie freeze is imminent, so if you needed motivation, go with that. If you can be bothered to spend the time trying to convince people like me that it's a safe and sane update for Ubuntu to pull in, we can talk after it's in Debian. [07:03] basically, my argument wouldn't be that it is absolutely necessary, but rather "not a huge number of users, if we've screwed up, it is unlikely to negatively impact many, but the gains are likely large for the few who use it" [07:05] ok, we'll follow the normal cycle, then [07:05] infinity, BTW, how imminent is jessie freeze, last I read was early November? [07:09] KjetilK: "Not many users" is, to me, actually an argument against updating, not for. [07:09] KjetilK: On the one hand, not many users would benefit and, on the other, very few people will be testing it to find bugs in time to fix them before release. [07:09] yeah, I can see that, fewer eyeballs [07:09] * KjetilK nods [07:10] KjetilK: As for the imminence of jessie freeze, I keep forgetting the exact date, and have just been treating it as "very soon" to push myself to get the things in that I need to. :P [07:10] hehe, good :-) === tvoss is now known as tvoss|test [07:14] infinity, BTW, since you're a DD, I just noticed https://packages.debian.org/sid/noip2 [07:15] which doesn't have a maintainer, but I find no WNPP bug on it, and the package is uptodate with upstream and appears sane... [07:16] Perhaps someone has orphaned it without telling anybody? [07:17] KjetilK: That's cruft. It's been removed from sid, note that it only exists on m68k on debports. [07:17] * KjetilK nods [07:17] KjetilK: https://packages.qa.debian.org/n/no-ip.html [07:18] KjetilK: Removed over 2 years ago. [07:18] infinity, yeah, but that's a different package, isn't it? [07:18] KjetilK: No, that was the source that produced the noip2 binary. [07:19] ah, ok [07:19] that's probably the reason why I didn't find it on on QA myself :-) [07:24] good morning [07:56] pitti`, guten Morgen :) [07:59] dholbach, ping [08:00] tvoss, pong === dholbach_ is now known as dholbach [08:47] jodh, Hey, wrt. my 2 machines that hang on reboot/shutdown I enabled debug mode and filed bug 1371469 [08:47] bug 1371469 in upstart (Ubuntu) "system hangs on shutdown/reboot" [Undecided,New] https://launchpad.net/bugs/1371469 [08:47] jodh, this is 100% reproducible but not immediately after boot [08:50] cjwatson, isolinux/lang no longer works in utopic, bug 1330416, could you help to take a look? [08:50] bug 1330416 in Ubuntu Kylin "In Ubuntu Kylin, default langauge in Ubiquity language chooser is not Simplified Chinese, isolinux/lang not honoured" [Critical,Confirmed] https://launchpad.net/bugs/1330416 [08:50] jibel: thanks. can you attach a log showing the shutdown? I've got a few questions but will add those to the bug... [08:51] jodh, which log? I attached syslog, is there any other? [08:52] jibel: you didn't actually attach the file. [08:52] jodh, oops, sorry [08:56] jodh, done. interestingly I cannot attach it uncompressed === vrruiz_ is now known as rvr [09:36] cjwatson, sorry to bug you again about software-properties - i keep getting told by different people that the issue around setting 14.09 as the series isn't resolvable or something like that [09:36] cjwatson, but obviously you told me differently, so i'm just checking on the truth of the matter [09:36] cjwatson, there's some proposed hacks to our tools that should be rejected if add-apt-repository is actually going to work in RTM [10:39] smoser: that's just a matter of making sure /boot/efi is mounted in advance and then running grub-install, I think [10:39] smoser: maybe you forgot the mount of the ESP? [10:40] Noskcaj: I do lots of ad-hoc seed maintenance but that sort of thing is a matter for the ubuntu-gnome team; I don't tend to get involved [10:42] ypwong: ok, added to this morning's amusingly long queue :-/ [10:42] brendand: I said roughly "I'm working on it" and that's still true. I intend to make add-apt-repository work [10:43] brendand: I think if you keep asking different people then you'll inevitably get people guessing :) [10:43] brendand: it certainly can be made to work without having to do the controversial base-files change [10:43] cjwatson, i'm not asking them for the fun of it :) [10:44] cjwatson, it just came up because robru is trying to land a change to phablet-tools that hacks around add-apt-repository completely [10:44] does anyone know if schroot has space restrictions? [10:44] cjwatson, he's getting his information from cyphermox [10:48] brendand: well you have the answer now [10:48] cjwatson, thanks for the help, tried to trace down the root cause as much as I can but does not know enough of gfxboot-theme to go further [10:49] ypwong: I may well not have time to look today; we'll see [10:49] ok === kgunn is now known as Guest93672 [11:44] When we do major modifications to code (scripts, programs, etc), is it required to update the copyright statements ? [11:53] recommended [12:02] cjwatson: I'm thinking of the makedumpfile script that you reviewed yesterday === _salem is now known as salem_ [12:37] cjwatson, i tried to show that in the paste. the d-i installed system does not have a /boot/efi. [12:38] smoser: this is my best guess sorry [12:38] the contents of /dev/sda1 is /boot/grub/grub (or at least very similar) [12:38] its not a filesystem [12:38] hang on, you are confusing me by talking about an EFI System Partition [12:38] this is ppc64el right? [12:38] what has EFI got to do with anything? [12:39] did you look at those pastes ? [12:39] only briefly, I had like five people pinging me about urgent things this morning [12:39] understandable [12:39] http://paste.ubuntu.com/8375494/ [12:39] that is information about what d-i set up. [12:39] you know if you stopped using sgdisk you would be less confused. [12:39] I'm not interested in sgdisk output - show me what parted says :) [12:39] you're confusing sgdisk with sfdisk. [12:39] ah you did, further down [12:40] i did show you what parted said [12:40] so ... why were you talking about an EFI system partition? [12:41] I'm very confused, there should be no such thing [12:41] because thats the gpt partition type of the /dev/sda [12:41] /dev/sda is gpt partitioned [12:41] and /dev/sda1 is of type C12A7328-F81F-11D2-BA4B-00A0C93EC93B [12:41] yeah, but that doesn't mean it has to have an ESP [12:41] hmm, that's thoroughly bizarre [12:42] agreed. [12:42] it should be a PReP partition [12:42] i thought it was just doing PReP too [12:42] so i just tried pretending as if it had [12:42] but telling grub to install to it says: not a PReP partition [12:42] if you do that. [12:43] for further confusion... i remembered that the thing that is doing the loading is petitboot [12:43] kexec based loader. [12:43] do you have a partman log from d-i? [12:43] so i suspect that it is actually mounting partitions and lookoing. because the menu you see in power-nv (no virt) is not a grub menu [12:44] i can probably manage to get you one. but i dont have one at the moment and the system is not being friendly to me. [12:44] while I understand that you're using d-i as the reference case that works here, this is not how I set up d-i to work [12:45] util/grub-install.c: grub_util_error ("%s", _("the chosen partition is not a PReP partition")); [12:45] that message? [12:45] maybe compare the GUID in the source with the one on disk [12:45] const grub_gpt_part_type_t template = { [12:45] grub_cpu_to_le32_compile_time (0x9e1a2d38), [12:45] grub_cpu_to_le16_compile_time (0xc612), [12:45] grub_cpu_to_le16_compile_time (0x4316), [12:45] { 0xaa, 0x26, 0x8b, 0x49, 0x52, 0x1e, 0x5a, 0x8b } [12:45] }; [12:45] and I guess there could be some bug in the comparison there [12:46] the d-i recipe for ppc64el in partman-auto is: [12:46] 8 1 1 prep [12:46] $primary{ } [12:46] $bootable{ } [12:46] method{ prep } . [12:47] cjwatson, ok. i have no idea how its booting. [12:47] which should turn into SET_FLAGS prep for parted_server [12:47] but i do have an idea as to why it might be different then you expected. [12:48] maas is feeding some preseed and that could be doing it. [12:48] infinity, do you have any idea how boot works on power nv ? [12:48] i'm thikning grub isn't actually involved. [12:48] oh and more importantly the prep filesystem [12:49] what is "prep filesystem" ? [12:49] how does one create that [12:49] oh just a virtual thing that causes parted to slam in the right guid [12:49] not a real filesystem [12:50] more a partition type than a filesystem, sorry for confusing term [12:50] ok. you can go back to other more pressing things. [12:50] it would be helpful to see the maas preseeding [12:50] let me see if i can dig that up [12:51] since we should really get that right ... [12:51] http://paste.ubuntu.com/8379633/ [12:51] but fwiw, it *is* right :) [12:52] it works. [12:52] having an EFI System Partition on a system that is not EFI is not right [12:52] it may work by virtue of being ignored [12:52] but it is a wart we should clean up [12:52] especially if it causes people to ask me really confusing questions :-) [12:53] ok, none of that preseeding should influence that, so I'd still like to see the partman log when you get a chance [12:53] where do i collect that ? [12:53] it's /var/log/installer/partman on an installed system [12:53] thanks. [12:54] when I was paying close attention to this, the partitioning was GPT { PReP; } [12:54] now since then we have done a major parted upgrade [12:54] so it *could* be that something went crazy there [12:55] but I think you should be patterning things after how it's meant to work :) (and while I appreciate wanting to pattern things after something that *does* work, this did work in the past) [12:59] smoser: right, just dug up the relevant bits of parted - it is actually a flag, "set prep on" in the parted CLI should do it for instance [12:59] or ped_partition_set_flag (part, PED_PARTITION_PREP, 1); [13:01] cjwatson, so you think it is getting set on the efi system partition ? [13:01] I think it's erroneously not getting set [13:01] and that the boot flag is getting set instead, which is mapped onto "please be an EFI System Partition" [13:02] these sorts of not-a-real-filesystem things are mostly done using flags in libparted [13:02] or real-filesystem-but-special-semantics [13:02] right. thats what i had thoguth [13:02] and i had other curtin that suc cessfully put a prep partition on [13:02] (at least something identified as prep) [13:03] but then system didnt boot [13:03] and it booted with that? [13:03] oh [13:03] um [13:03] well, let's get d-i in the right shape again and then model on that? [13:04] cjwatson, also remember that there are 2 cases here. [13:04] one power-nv and one powerkvm. [13:04] right, I'm not hugely familiar with the differences [13:04] that makes 2 of us [13:04] :) [13:05] powerkvm is roughly equivalent to running qemu-system-ppc64? [13:05] with slof [13:05] well, it *is* running qemu-system-ppc64 [13:05] right, so that's what I tested with in the past [13:05] right. and that reads prep for sure. [13:05] power-nv I confess total ignorance of [13:05] -/5 [13:05] right. that just means "bare metal" where ubuntu would be the hypervisor [13:06] but we ought to have the same partition/boot layout on both, right? [13:06] and the thing that loads that is 'petitboot'. [13:06] chaining to grub? [13:06] remember the conversation with anton about petitboot reading grub ? [13:06] no :) [13:06] oh no? you were on that... they talked abou it. i think that is what is happening. [13:07] unless you mean the one really really early on [13:07] i *think* petitboot (which is a linux kernel + busybox) somehow finds things to boot. [13:07] and shows you a menu [13:07] and it labels them suspiciously similar to the way grub would. [13:07] but you're most certainly not interacting with grub [13:08] so, for prep, the general idea is that the prep partition is basically just a zoned-off chunk of disk, and a GRUB core image is basically dded into it [13:09] any other boot loader that wants to chain to it should be looking up the prep partition by guid and then chaining it in the obvious naïve way [13:09] I'm assuming that it is expecting the chained loader to be 32-bit BE [13:12] that explaination of prep seems to fit with what i've seen. so i wasn't completely off. [13:12] if we're now creating an ESP by accident, then it's possible that powerkvm is now broken [13:12] or maybe slof handles that [13:13] I don't see anything in my copy of slof/fs/packages/disk-label.fs that would though [13:15] pitti, thanks for the quick action... much appreciated! [13:32] smoser: Booting natively completely ignores that partition and just scans all mountable Linuxish partitions for grub and yaboot configs and mashes them together in petitboot. [13:32] smoser: So, the PReP thing only matters for VMs, but we use it everywhere for consistency, and portability of disk images, and to not drive us batty. [13:33] smoser: Oh, and the PReP thing also matter of booting natively as a PowerVM partition. [13:33] thats what i thought. [13:33] so i'm not sure why petitboot doesn't like my curtin based install [13:34] but the new firmware delivered a much nicer petitboot with 'rescan devices' which is crazy useful. [13:34] :) [13:34] Shiny. [13:35] smoser: oh so maybe you need to be diffing /boot/grub/grub.cfg and that kind of thing then? [13:35] cjwatson, yeah. [13:35] hadn't occurred to me that power-nv would do that! [13:35] well i told you! [13:35] what i suspected [13:36] but its still kind of yucky. [13:36] mostly confirmed that they're parsing grub config [13:36] which as seen here could be buggy. its also possible that now my curtin changes would work (solved by my firmware upgrade) [13:36] right now i'm doing a d-i based maas install [13:36] and will get cjwatson the requested parted log. [13:37] I guess I missed that, sorry [13:38] I think I thought you mean "mounting partitions and looking ", not "mounting partitions and looking " === Guest93672 is now known as kgunn [13:38] ok. so i'll get that system installed into d-i [13:38] and then i'll get cjwatson and infinity access to it. [13:39] cjwatson can feel free to ignore that. [13:39] and infinity should dist-upgrade it to utopic [13:39] where in theory we have magic pixies and kvm support === pitti` is now known as pitti === flexiondotorg_ is now known as flexiondotorg === mapreri_ is now known as mapreri [14:20] cjwatson, d-i install of utopic [14:20] hardware-summary: http://paste.ubuntu.com/8380127/ [14:20] lsb-release: http://paste.ubuntu.com/8380128/ [14:20] partman: http://paste.ubuntu.com/8380129/ [14:20] status: http://paste.ubuntu.com/8380130/ [14:20] syslog: http://paste.ubuntu.com/8380131/ [14:23] hmm, the boot flag is already in place [14:24] I wonder if that matters [14:24] and whether it would behave differently on a blank disk [14:26] Hello peeps [14:28] infinity, https://bugs.launchpad.net/ubuntu/+source/powerpc-ibm-utils/+bug/1371624 [14:28] Launchpad bug 1371624 in powerpc-ibm-utils (Ubuntu) "update_flash is /bin/sh but contains bash" [Undecided,New] === FlannelKing is now known as Flannel [14:29] pitti: is postgresql-server-dev-all expected to stay in main for >utopic? [14:29] Wondering where to build-dep on that or a specific version (for bacula) [14:29] rbasak: I wouldn't see it, if anything needs it it's fine in main [14:30] rbasak: usually it's a build-dep of server-side extensions [14:30] but we have pretty much all of them in universe [14:30] rbasak: bacula? I thought this was a db client, not an extension [14:30] No idea why it build depends on that, but it does. [14:31] It FTBFS right now because it depends on postgresql-server-dev-9.3 [14:31] pitti: so I'm wondering whether to change it to postgresql-server-dev-all, or to -9.4. [14:31] rbasak: ideally it should work with libpq-dev only [14:32] rbasak: if it needs some extra server-side include file for poking in internals, then I think -dev-all should be ok [14:32] jamespage, Hi! Can you please review/comment on https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298 ? [14:32] rbasak: (I mean within the realm of already being deep in hack territory :) ) [14:39] pitti: what do you think about syncing scribus now? I uploaded 1.4.4 to sid (should go to testing at the next britney run) and I'd like utopic shipping it. I'm not sure if a FFE is needed, though... [14:43] mapreri: it's two microreleases; most projects only fix bugs in microreleases [14:43] mapreri: so a quick review of the changelog is in order (and testing a build on utopic, of course), but it's probably okay [14:45] pitti: yes, the most of the changes are bugfixes and really little changes. http://sources.debian.net/src/scribus/1.4.4%2Bdfsg1-1/ChangeLog/ [14:46] pitti: do you prefer me upload it to a ppa before syncing? [14:46] (I guess it builds fine, though :P) [14:46] mapreri: yes, indeed [14:46] mapreri: if you sbuild it locally, that's good enough [14:46] smoser: Yeah, I have a Debian bug for that, fixing in the next upload. [14:47] pitti: to be honest, I never tried to build it in a utopic chroot, only in sid... [14:47] mapreri: I'll give it a spin here, and sync if it works [14:47] pitti: great, thanks === halfie_ is now known as halfie === henrix_ is now known as henrix === DalekSec_ is now known as DalekSec === sil2100_ is now known as sil2100 === tarpman_ is now known as tarpman === roadmr_ is now known as roadmr_afk === Laney is now known as Guest37661 === kees_ is now known as kees === DalekSec_ is now known as DalekSec [15:09] have a nice we all [15:09] ciao! === sil2100_ is now known as sil2100 === lan3y is now known as Laney === Ursinha-afk is now known as Ursinha === Saviq_ is now known as Saviq === balloons_ is now known as balloons === debfx_ is now known as debfx === balloons is now known as Guest35774 === jpds is now known as Guest26752 === culot_ is now known as culot === pfsmorigo is now known as Guest91417 === Trewas666 is now known as trewas === Guest35774 is now known as balloons_ === Lutin is now known as Guest7993 === lynxman_ is now known as lynxman === roadmr_afk is now known as roadmr === _morphis is now known as morphis === gusnan_ is now known as gusnan === FlannelKing is now known as Flannel [17:03] cjwatson: ok, I'm here now :-P [17:04] cjwatson: so if we created a new click database, how could we install development packages to it without conflicting with installing regular packages from the store? [17:04] mhall119: so I'd say stacking a test database on top temporarily would be the best answer, except that that currently requires root [17:04] (just to create the test db) [17:05] actually let me just check that assumptio n [17:05] cjwatson: could we create this when the user enabled developer mode and just leave it in place? or would that conflict with installing packages from the store? === Guest91417 is now known as pfsmorigo [17:05] mhall119: I'm thinking something more transient than that [17:06] zbenjamin_: ^^ this is related to our discussion earlier [17:06] mhall119: as in something controlled by an environment variable, so it would be confined to just the process context of the SDK, and could be a temporary directory [17:06] even better [17:07] mhall119: so right now this isn't exposed in the CLI, although the library interface allows it - look at click/commands/*.py and notice that there's a db_dir=None param passed to db.read() [17:07] oh actually [17:07] click install --root= [17:07] that stacks a directory on top [17:07] zbenjamin_: do we currently use click install of pkcon install-local? [17:09] cjwatson: if we did that would it replace $HOME/.local/share/applications/.desktop? [17:09] I don't know, this is a few too many questions to fire at me all at once [17:09] probably [17:09] I suppose I should put this all into a doc [17:09] this might not be perfect right now but I think it is the correct direction [17:10] I imagine you use pkcon install-local right now, which has the effect of running click install as root so that it can ensure that the app can't write to its own code [17:10] you probably do want to keep that part of it so that app authors can test in a properly confined environment [17:11] that said the packagekit-based interface is not long for this world; I'm writing a new native click d-bus interface [17:11] basically because packagekit upstream is killing plugins, see http://blog.tenstral.net/2014/09/listaller-back-to-the-future.html [17:15] cjwatson: zbenjamin_: I'm adding these bits to the bottom of https://docs.google.com/a/canonical.com/document/d/1i5KRNoc-UXYxT3xFDl9YKETwaa0I2yIUG33Oi_pyeYc/edit [17:18] mhall119: it might work for the SDK to just set $HOME [17:18] to a temporary dir [17:19] possibly, not sure what side-effects that might have on the app's runtime [17:20] mhall119: right; but I think in general the SDK should be giving developers a clean test environment? [17:23] I can see arguments for both ways [17:26] I think if you go with the approach that they don't get a clean test environment, you will find it extremely difficult to satisfy the requirement of not conflicting with installing packages from the store [17:27] yeah, I suppose the developer can come up with a way to pre-populate test data if they need it === sarnold_ is now known as sarnold === balloons_ is now known as balloons === superm1_ is now known as superm1 === roadmr is now known as roadmr_afk === zbenjamin_ is now known as zbenjamin [19:49] mhall119: cjwatson: right now we use pkcon to install the packages. [19:50] mhall119: cjwatson: i would like to not need root privs for that, because the only way would be to somehow echo it into the commandline which kind of is ugly [19:50] zbenjamin, not necessarily [19:51] ogra_: that means? [19:51] ogra_: using a dbus interface? [19:51] adb shell "echo -e '#\x21/bin/sh\necho $PASSWORD' >/tmp/askpass.sh" [19:51] adb shell chmod +x /tmp/askpass.sh [19:51] adb shell SUDO_ASKPASS=/tmp/askpass.sh sudo -A [19:52] ogra_: this is not ugly? ;) [19:52] i admit you still need to echo the PW once that way [19:52] but better than adb shell "echo $PASSWORD|sudo -S " [19:52] ogra_: i would prefer to not echo the password around, for a real phone user its not just any password [19:52] which yoou would need to do for every command [19:53] will a real phone user use developer mode at all ? [19:53] my mom wouldnt [19:53] ogra_: of course [19:53] (she wouldnt even know what it meaans) [19:53] ogra_: of course not ;), but a developer using and developing for the phone would [19:54] you could indeed dump a dbus interface in place [19:54] but that means poking more security holes (even though they are small) [19:54] yeah thats a problem :/ [19:55] ogra_: i want transaction support in click ;) [19:55] ogra_: click rollback [19:55] hah [19:58] ogra_: its kind of sad that there is no API that can elevate a process to higher rights in linux when you know the password, then i could just open a communication channel that is encrypted to send the password [19:58] zbenjamin, lets discuss that at the sprint [19:58] ogra_: ok! [19:59] dev mode as is is an awful hacked android dev mode, i think we can really do better [20:00] ogra_: yeah :) [20:00] (with the right amount of time and planning involved) [20:01] zbenjamin: what would you need root for? [20:02] mhall119: click install needs root, and cjwatson suggested to create a temporary click db what would need root as well === roadmr_afk is now known as roadmr [20:03] zbenjamin: he also said he's adding a d-bus interface to click so as to replace packagekit [20:03] which I assume means we can run something as the normal user and have click install it as root [20:03] just as pkcon install-local does today [20:04] because we're going to have to support that for store installed apps too [20:04] you will still need a way to elevate privs, authenticate or some such [20:04] (or a key as zbenjamin said above) [20:04] why? [20:04] mhall119: yep, that also means to make the upstart jobs aware of the temporary database [20:05] mhall119, because you dont want everyone to be able to do stuff with root privs on your device ? [20:05] zbenjamin: why couldn't that just be something passed over dbus? [20:05] ogra_: we want them to install packages [20:05] right [20:05] which they can today [20:05] without root privileges [20:05] yes, but if the desire is to do that with higher privs in the future [20:06] which is how i understand the above [20:06] I don't think we'llneed higher privs [20:06] mhall119: could be , but the app still should be started confined and i would like to use a stable API/service for that so we do not break on every change. We had that before and it burned us badly [20:07] zbenjamin: that's the goal, the only difference from the SDK's perspective would be that it tells the install command to install to /tmp/sdk-dev/ or something like that [20:07] mhall119: yeah and start it of course [20:07] yes that too [20:07] mhall119: plus we need signals that tell me about the state of the app (at least started/stopped and exit code ) [20:08] zbenjamin: do we already have that? [20:08] mhall119: yes upstart does that [20:08] then it should be the same with cjwatson's replacement [20:08] mhall119: you want to look at libupstart i think [20:09] * mhall119 doubts that he really wants to :) [20:09] ok probably not ;) [20:10] zbenjamin: you call upstart-app-launch or something like that right? [20:10] I assume it uses envvars liek $HOME or $XDG_* to find the app to start [20:10] mhall119: its ubuntu-app-launch now, and i use the backend library directly, not the frontend [20:11] mhall119: uh tedg would be the right guy to ask that, it should be upstart jobs [20:11] zbenjamin: I still assume there's a way to tell it where to look for apps [20:11] ok, we'll find out from ted [20:12] lucking all of this is code that we're writing, so the only real obstacle is developer time [20:12] unfortunately the only real obstacle is developer time :( [20:13] :/ [20:13] mhall119: only thing i'm concerned about is that with a change like that we would break compatiblity to older phone images. [20:14] mhall119: we have no way of asking the phone if it has features like that, so the script can adapt [20:14] i hardly doubt we can use the same commands for both ways of installing a app, except only setting a env var would change the behaviour of all used commands [20:30] mhall119, I'm confused, what are you trying to do? [21:05] tedg: we want to install a click package somewhere other than where the store installs and run the app from there [21:05] mhall119, Why? [21:05] tedg: the case is app development, running an app project from the SDK currently installs it normally, which conflicts if you already have the app isntalled [21:06] so I can't have the stable version of my app on my phone *and* test the development version on my phone [21:06] mhall119, Clicks are all per-user, so wouldn't it make more sense to just have it be another user account? [21:06] So I could have my stable account and my dev account. [21:06] Or I could install the dev in my stable account right before shipping. [21:06] tedg: and could we run it on the stable account session in Unity? [21:07] I'm confused. You'd be two users. You log in as one, or the other, or switch between them. [21:07] Just like all Ubuntu systems. [21:07] tedg: we don't have multi-user on the phone, but even if we did I don't think that's a very developer friendly solution [21:08] tedg: click allows (or will allow) the SDK to install the dev click package in a separate space, we would just need to launch it under confinement from that place [21:08] mhall119, We do have multi user, we just don't have UI for switching users. That's a solvable problem. [21:08] tedg: they're all solvable problems, it's just a matter of which one is easiest/most appropriate to solve for this [21:09] mhall119, I don't understand why a) you wouldn't change the name (i.e. so it'd show up with two icons in the apps scope) or b) you wouldn't change the version, so that you could detect which you're running. [21:09] Both of those options work today. [21:09] tedg: the appid is used in multiple places, which makes it more complicated to change especially for scopes where it's in the source and binary filenames [21:10] even if you change the version number you have to uninstall the currently installed one before you can run the dev one [21:10] mhall119, That's not true. It's all ref counted. Each user on the system can have different versions of the app. [21:10] each user can, yes [21:11] So you don't have to remove the old one. [21:11] but I currently can only use one user [21:11] You just have to say "this is the version I want" [21:13] so here's my use case, I have uReadIt 1.0 installed on my phone. It works, I use it every day. But now I'm starting on 2.0, it won't be ready for months. I want to be able to test 2.0 on my phone while I develop it, but still be able to use 1.0 on the same phone until 2.0 is finished and in the store [21:13] So you want to have two apps installed. uReadIt 1.0 and uReadIt 2.0 [21:13] I really don't care if uReadIt 2.0 is installed, I just want to be able to run it on my phone from the SDK === mnepton is now known as mneptok [21:14]