[00:10] hello [00:12] I would not want to bother with a problem related to bugs, but I think I would like to know something about jobservice and jobs-admin tools. [00:13] I would like to know if there are plans to work on the code of this program [00:13] here is our findings so far, about it : it does not work in a way which allows managing services. [00:14] here is the best post I could write after I tried to dig in and test: [00:14] http://beta.linuxvillage.net/index.php/topic,297.msg2231.html#msg2231 [00:14] and after I have been commenting on one of the latest bugs reported regarding this program. [00:18] melodie: heh, the changelog.Debian.gz doesn't paint a pretty picture. it looks quite stale [00:18] hi sarnold [00:19] melodie: what I think you actually want is an .override file -- no gui, no dbus involved :) http://upstart.ubuntu.com/cookbook/#override-files [00:19] melodie: just echo manual >> /etc/init/whatever.override and that 'whatever' job will not start automatically at boot [00:20] (finding this feature was what made me prefer upstart over sysv-init :) [00:20] sarnold what I wish is not an override-file but a handy tool fit for newcomers (the ones who are ready to use their brain and learn how to deal with an Ubuntu distro) [00:21] melodie: ah, darn. :) [00:21] sarnold if I need a special setup in Archlinux, and do things by hand I'll do it, but in Ubuntu, I don't believe it :D [00:21] melodie: So what you want is an upstart job GUI? That shouldn't be super-hard. [00:22] RAOF the gui exists, but some things don't go straight in the code and the man who wrote much about it had done a fix which he accidentally deleted.. in 2011 and never replaced as it seems [00:22] you can notice in Raring it is the same version used: [00:22] http://packages.ubuntu.com/search?keywords=jobservice&searchon=names&suite=raring§ion=all [00:23] RAOF i mean the code of the background : jobsystem. the gui might be fine. [00:23] melodie: I'm not entirely sure what you're after? Do you want to work on the code? Go ahead! Do you want someone at Canonical to make it their job to work on the code? That's probably not going to happen. [00:23] in fact all is really beautiful in Ubuntu, so many nice User interfaces, just this one does not work [00:24] melodie: most users only have services installed that they want to run anyhow.. [00:24] RAOF if I would know I would try, but I don't have that knowledge. I know only about the system, testing, bringing pieces together.. I participate as I can but don't code [00:25] sarnold this is less and less true. see cups ? [00:25] it can be installed and runned only once a while, or bluetooth or... [00:25] melodie: this specific tool looks like it was written with upstart 0.6 in mind; 1.3 and newer provide the override files that would make the tool only about a thousand times easier to write... [00:25] melodie: Why not code? This is probably a good project to start with ☺ [00:26] RAOF I just registered this year to two places to try to learn a little. at coursera.org and at cs50.tv : and I have a very full life, so it's not going to be easy. [00:26] I just wanted to know if Ubuntu is planning to review this code which looked very promising. [00:27] I do not believe that anyone is currently planning to touch that code. [00:27] melodie: I'll try to keep this in mind next time someone comes forward and says "I want to help but don't know where to start" :) [00:27] example, at cs50.tv they have provided an appliance under the shape of a Fedora tweaked for the needs of the course. I don't know much about Fedora, and there are a bunch of things which I really prefer in Ubuntu. [00:28] just their job service management tool : we would all like to have the equivalent in Ubuntu :P [00:29] see for the testing purpose and for the post written I have taken a pair of hours. I wanted to have a talk about it with people who know the value of good user interfaces in Ubuntu. This is done now. (and it's very late in the night here. :) ) [00:29] :D [00:30] sarnold you say something strange : if I'd know how to debug a python code I could try to bring better feedback; what tool do you use to debug a python script ? [00:31] melodie: I try to replicate problems in the python REPL interative interpreter -- copy-and-pasting function definitions as I modify them from another file, when they grow too large.. [00:31] melodie: it isn't very good :( but it works for me well enough that I haven't looked much further [00:34] I thought I would try to find who maintains it, but it seems the original maintainer is not involved anymore : http://packages.ubuntu.com/raring/jobservice [00:34] " python REPL interative interpreter" : no idea what it is. [00:35] I might discover it later if I can stick to the courses online... or perhaps not. [00:37] sarnold RAOF thanks to both [00:37] I can read here: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss among else: [00:38] " Point of contact for Ubuntu users to reach Ubuntu developers [00:38] " [00:38] so I think I'll try to post there once about this issue. [00:38] I'll test it on more versions before, to be a better idea of the extent of the issue [00:42] good night [00:48] oh bother, too bad she's gone while I was away.. there's really no point to her investigating that program further, it's been abandoned for over two years... [01:16] ScottK: kde4libs is trying to yank a ton of stuff into main. Looks like a few suggests got upgraded to recommends. Any idea if that was intentional or a merge oops? [01:19] ScottK: Hrm, based on history in the package, I'm going to assume it was just a merge oops, and upload a fix. === doko_ is now known as doko [01:31] Daviey: Can you get someone on your team to take ownership of the MIRs required for the new puppet and python-testtools rdeps? [01:32] Daviey: See http://people.canonical.com/~ubuntu-archive/component-mismatches.svg [01:44] infinity: probably. [01:44] Go for it. [02:05] Riddell: ^^^ === hggdh_ is now known as hggdh === barry` is now known as barry [03:38] Good morning === elky` is now known as elky === jamesh_ is now known as jamesh === G4MBY is now known as PaulW2U === broder_ is now known as broder [06:38] good morning [07:05] Hi.. Could anyone point me forward with this lightdm issue? I'm trying to figure out how to make a proper fix for this as this shows up on diskless workstations all the time.. https://bugs.launchpad.net/lightdm/+bug/1172752 [07:05] Launchpad bug 1172752 in Light Display Manager "Race condition in lightdm greeter setup" [Undecided,Confirmed] [07:15] vmlintu: Hm. Seems reasonable. I don't suppose you can get a reliable test case that we could add to the testsuite? :) [07:16] vmlintu: You've got two options to take that forward - branch lp:lightdm, apply that fix, and propose a merge back to lp:lightdm, or hope someone else does that. [07:19] * RAOF heads to the shops for a bit. [07:24] RAOF: I haven't been able to change the environment so that the race condition would show up all the time, so no test case at this point.. [07:26] But I really don't like the fork()->vfork() fix I wrote in the launchpad bug report as it just hides the unnecessary fork()->execlp()->kill() cycle. Getting rid of that would make the fix unnecessary.. === smb` is now known as smb === Bluefoxicy_ is now known as Bluefoxicy [10:36] Is errors.u.c having a sad day? "An error occurred while trying to load the most common problems" [10:43] cjwatson: I so much want to work on the new app installer / packaging format [10:53] zyga, i think there are UDS sessions next week [10:53] ogra_: I'll be there if I can [10:54] ogra_: but this is something I wanted ubuntu to have for a long time [10:54] ogra_: and now there is both the desire and the actual need [10:54] I was thinking about dependencies though [10:54] classical dependencies cannot be allowed [10:55] but I was thinking about base os dependencies that might make this applicable to many more packages, without adding any additional issues that the proposal is trying to avoid [10:55] * zyga so much wants to talk to cjwatson about this later [10:58] Right, as I mentioned briefly in my post I was considering permitting a few base profiles; it'd be useful if you have experience of what other systems call things there [10:59] The way I'd be inclined to implement this would be to allow packages to install files in /usr/share/click-package/profiles/ whose presence indicates that a profile is present [11:00] cjwatson: I don't think I understand base profiles exactly, I'm somewhat familiar with what gnome is trying to build now but I wasn't aware of any profiles there [11:00] I initially called this "base system", but somewhere in my research I ran across the term "profile", I think via the GNOME app bundle stuff, and I prefer that term [11:00] http://blogs.gnome.org/alexl/2013/02/01/developer-hackfest-status/ mentions it [11:01] Well, he calls it variously "ABI" and "profile" there [11:01] cjwatson: ah, I understand what that may be now [11:01] Maybe "ABI" is clearer [11:02] cjwatson: I was thinking about allowing dependencies on a subset of current packages, specifically those marked as 'pure' (no maintainer scripts). The pure set would be garbage-collected with the root set being all the installed apps from the new model. The pure set might be applicable to some non-default libraries, static files, etc [11:03] cjwatson: but this is not for the tablet / phone target, more like a liberal view of what packaging of desktop might look like later [11:03] The problem with using system package names in this is that you can very easily end up needing to scan the system dpkg database [11:03] cjwatson: dpkg being slow, you mean? [11:04] Indeed [11:04] cjwatson: yeah, that would be a pain [11:04] Which is why I'd prefer to have a separate namespace for ABIs applicable to app packages [11:04] cjwatson: also, the new package format might be tuned to 'non-critical' stuff so it might not fsync that badly [11:04] cjwatson: separate namespace makes sense, yes [11:04] Eh, I just turned off fsync :-) [11:04] Doing so made a very noticeable difference to overhead [11:04] cjwatson: well, you may still want some 'fsync'-like thing for base os [11:04] Base OS remains with dpkg [11:05] cjwatson: a few years ago I toyed with something I called dpkg-connector [11:05] This is absolutely not intended to replace dpkg [11:05] cjwatson: basically a way for foreign system to tell dpkg that it installed something [11:05] cjwatson: I know [11:05] cjwatson: then dpkg would know about those new files and could be, eg, asked to remove that package [11:06] Mm, I was trying to keep complexity down by keeping things separate. The other thing is that we may be permitting multiple versions to be unpacked in parallel with symlink-flipping, which makes some sense with something like a multi-user tablets [11:06] *tablet [11:06] I suspect it may not be guaranteed to fit into dpkg's view of the world very well :) [11:07] cjwatson: so while I installed a game through steam or some python code with pip, dpkg could see and remove that, it would also prevent clashes if files colided [11:07] There are certainly plenty of possibilities [11:07] cjwatson: yeah, multi version is interesting [11:07] cjwatson: as are non-root and free-path usage in general [11:07] There'll never be clashes in this model (well, assuming no dpkg package ever installs under /opt/apps.ubuntu.com/ or whatever) [11:07] cjwatson: well, ideally, true [11:07] Pretty much guaranteeably [11:08] The above is the only caveat [11:08] cjwatson: as for that, do you think stuff like SD cards are an issue [11:08] cjwatson: eg, I want to install this game to SD cards and that game to root memory (or the system chose to do so) [11:08] You mean installing some apps to phone memory and some to SD cards? [11:08] cjwatson: yes [11:09] cjwatson: then you'd need to either make /opt/apps.ubuntu.com a magic fs or allow for some flexibility [11:09] cjwatson: I wonder if SD card story is at all specified for ubuntu touch [11:09] I confess I haven't thought much about that; the model would make it moderately straightforward if we wanted to though, since the multi-version thing implies having apps run from symlinks [11:09] cjwatson: so symlinks would glue that back? [11:09] So it's not difficult to have symlinks into more than one all-the-apps type directory [11:10] cjwatson: indeed [11:10] (*handwave*) [11:10] cjwatson: do you think that package model is bound to apps? [11:10] cjwatson: so that people never have apps != packages [11:10] can you rephrase? [11:10] cjwatson: sure, sorry [11:11] cjwatson: do you think that your proposal assumes that each thing being delivered by the new package format is a single application [11:11] cjwatson: so non-app payloads and multi-app payloads are forbidden [11:12] At present yes [11:12] cjwatson: do you think there is value in having something like that back on the desktop? [11:12] Well, the only thing stopping non-app payloads would be making sure they don't deliver a desktop file I suppose [11:12] Multi-app payloads, not sure of the use case [11:12] cjwatson: so that some things could be delivered this way later [11:12] desktop file> or whatever the integration there is [11:13] cjwatson: for non-app payloads, app management is an issue [11:13] Right. Somebody else's problem ;-) [11:13] cjwatson: users would need to be presented with two views "what you see on the app launcher screen" vs "what you have installed" [11:13] cjwatson, that mail should probably go to the ubuntu-phone ML in parallel [11:13] ogra_: feel free to forward/bounce it [11:13] I don't wish to spread discussion across multiple lists though [11:14] cjwatson: mulit-app, not sure but I know that many phone apps from single vendor really suffer (bigger than needed) because they cannot share anything [11:14] cjwatson: it might be a niche use case, but I wanted to ask [11:14] done [11:14] cjwatson: it's also a management problem a bit, when you want to remove application, like you currently do in the desktop, that removes, eg, other apps for some reason [11:14] I think that's more data sharing than multi-app payloads [11:15] I'd like to put that on the shelf for now though [11:15] cjwatson: ok [11:15] hello [11:15] I would like to have some answer for that at some point, but probably not for 13.10 [11:15] cjwatson: one thing I'd love to see out of this is a way to see this system on the desktop eventually [11:15] Sure, the buzzword is "convergence" :) [11:16] cjwatson: not for everything but for some use cases and growing [11:16] cjwatson: as it's far easier to grasp than current packaging, I suspect [11:16] I'm sensitive to many desktop applications having necessarily much more complex structures though [11:17] cjwatson: have you though about 'in-app purchase' so to speak, where you get one app but then get additinal slivers of data (magazines, levels) that are also downloaded and stored? [11:17] cjwatson I am glad you are here, I have a question related to some bug reports around a gui admin program. [11:17] may I ask ? [11:17] cjwatson: I don't think that is the case, look at all the steam games, there are classes of apps that would just fit right in [11:17] So I know it's something that not least my management would like to have - but I want to make sure it doesn't cause massive scope creep [11:18] zyga: in-app purchase might fit into the broader project but not into my slice of it; ask aquarius [11:18] cjwatson: I don't know how other platforms handle that, I suspect that in-app thingh is totally separate and the data they get is just not managed by the package system [11:18] melodie: I'm likely to be a terrible person to ask about anything GUI [11:18] cjwatson: ok [11:18] cjwatson: in-app purchase is just the keyword, I'm not interested in the actual purchase path, just the data [11:19] You could have the in-app-purchased data files be a click package, so you have com.valve.steam.half-life and com.valve.steam.half-life.more-guns, sure [11:20] yeah, that might work [11:20] However you'd have to be careful about lookup paths and such, since click packages aren't allowed to install integration points for other packages [11:20] cjwatson there are bug reports still not solved since about 2010 or 2011 concerning jobservice which affect the use of jobs-admin, at the bugzilla. I'd be very happy and many other users too I'm sure if the devs would look at it closely. I thought I would drop a word about it at the ubuntu-devel mailing list : do you think it is a good idea ? [11:20] (A core requirement is for them to be totally declarative) [11:20] then the app could request that thing to be installed either at high (via the store) or low (download by itself and ask the package manager) level [11:20] melodie: No idea, sorry [11:20] cjwatson ok, thanks anyhow [11:21] cjwatson: integration points? [11:21] melodie: I mean I don't object to the mail as a moderator, but I don't know if it's useful [11:21] cjwatson: also sandboxing might be an issue [11:21] cjwatson: where com.vendor.app cannot see com.vendor.app.addon [11:21] zyga: Well, if you want to have apps (or click packages, anyway) hooking into other apps, they'd likely need to link files around and stuff, the sort of thing that's done by hooks provided by system packages [11:21] cjwatson I don't either, but I don't quite see what would be better to get someone have a close look there [11:22] cjwatson: I don't thing links are needed [11:22] (so, say, we might have a dbus-service hook that lets you link files into /usr/share/dbus-1/services/ so that dbus-daemon can see them) [11:22] cjwatson: perhaps enumeration of some sort [11:22] cjwatson: ah [11:22] cjwatson: I see what you mean [11:22] cjwatson do you know of someone in the Ubuntu dev team who I could try to join preferably ? [11:22] and packages typically don't want to enumerate some not-specified-up-front list of directories looking for files - it's an awkward thing to do [11:23] cjwatson: it's easy to stray to related but not quite same fields in this conversation [11:23] melodie: perhaps James Hunt can help, though he doesn't seem to be around right now [11:23] cjwatson: no, I meant, eg, some game wanting to enumerate its add-ons [11:23] (jodh) [11:23] zyga: Right, but I think it's a similar problem [11:23] cjwatson I'll keep his name in mind. thank you [11:23] cjwatson: where the game knows the add-on identifier [11:23] cjwatson: 'eg com.vendor.game.add-ons' [11:24] cjwatson: and each packaged thing can declare to be that [11:24] I suppose since we're using a reversed-internet-domain scheme for app names we can have a facility to enumerate things under a domain [11:24] cjwatson: anyway, I don't want to steal your time, I'm looking forward to the UDS conversation [11:25] don't worry, this is interesting even though I don't have all the answers (and don't expect to) [11:25] cjwatson: having a rev-domain might be security issue though [11:25] Yeah, well, it depends on how you're using the results of the enumeration [11:25] cjwatson: eg, can anyone distribute packages that hook into my domain? [11:25] yeah, exactly [11:25] internal vs public [11:26] it's also interesting on the desktop a bit [11:26] or actually [11:26] on the shell / cli [11:26] cjwatson: imagine where shell you get is empty, and you install apps into your profile explicitly [11:26] cjwatson: and apps only declare what they provide (commands) [11:26] cjwatson: scripts are tricky then (they would need to 'pull in' commands given some long / unique ID) [11:27] cjwatson: but namespace clashes [11:27] cjwatson: and general mess of command line might be eventually cleand up [11:27] Yeah, right now I don't see this working very comfortably for tools you run from the command line [11:27] cjwatson: yeah [11:27] You'd either need a ridiculous path or some proprietary shell extension [11:27] That said, nothing to stop a system hook linking script-like commands into a single directory [11:27] cjwatson: /*/bin/ would likely remain as it is forever for compatibility [11:28] Namespacing would make the names awkward though. I don't think you really want to invoke com.ubuntu.shiny-command from a shell [11:28] cjwatson: but then you could use app store app to add 'some-tool' into your profile [11:28] As I say, I don't actually feel the need to solve all problems with this :) [11:28] cjwatson: scripts would, you would import the short name of your choice [11:28] cjwatson: :) [11:28] * zyga has a brainstorm inside his head [11:29] I mean, I'm OK with confining this to solving a smaller problem well if that's what it takes to keep the scope manageable [11:29] cjwatson: I fully understand that [11:30] cjwatson: I'm just excited to see that topic being touched and the possibilities it opens down the road === _salem is now known as salem_ [11:30] Not that I want to shut down discussion; but perhaps a sensible division is to think about things that aren't currently being reasonably well-served [11:31] cjwatson: I think what you mentioned in your email is a great start: no deps/no conflicts, confined directories, new package / install tools [11:31] (proprietary shell extension, above> by which I mean proprietary as in "our own", not as in licensing) [11:31] cjwatson: :-) [11:31] cjwatson: I would see that as a patch to [db]ash eventually but perhaps as a symlink farm now (shell stuff) [11:32] anyway [11:32] I do expect to take some heat given that there are other tools like this out there, the why-didn't-you-just-contribute-to-them thing [11:32] cjwatson: do you keep the code in any project yet? [11:32] cjwatson: yeah, I think what you are doing is okay [11:32] cjwatson: other tools usually birng impedance [11:32] cjwatson: and might diverge in goals later [11:32] Still open to using something else if it's sufficient; the problem as I saw it was that they were all kind of 50% solutions so it wasn't clear it would actually help either us or them [11:33] cjwatson: though we should look at reusing ideas and maybe forking something if that saves time [11:33] * zyga checks your email again [11:33] It will be in the click-package project; just trying to get the proof of concept slightly less PoC-y first [11:34] There will definitely be branches there before UDS [11:34] cjwatson: as for existing systems, is there anything other than android that you looked at? [11:34] cjwatson: it might be good to enumerate all existing solutions (including those that we cannot use at all, eg, proprietary stuff) [11:34] cjwatson: I'd love to help with that if you want [11:34] I mentioned several briefly in my mail [11:35] I would definitely appreciate help with a better competitive analysis [11:35] I looked through most of the mobile app store packaging formats I could find === jelmer_ is now known as jelmer [11:35] cjwatson: I guess one thing that is blurry is if this is really defining the packaging system (however app centric as it may be) or actual applications themselves [11:36] android, tizen basically zip files with varying layouts and manifest files specific to their requirements; sailfish seems to be RPM though I couldn't find the specifics; iOS I did look at briefly although the answer does not appear to have stuck in my head [11:36] cjwatson: that's about right [11:37] cjwatson: to be fair I'd use zip as well [11:37] I think we definitely want fairly strong conventions for how things like QML and HTML5/CSS apps for the phone/tablet are laid out [11:37] cjwatson: deb == ar + tar + compression [11:37] cjwatson: and that sucks for some purposes [11:37] cjwatson: zip is rather better in general [11:37] cjwatson: agree on conventions [11:37] cjwatson: eg, random access [11:38] cjwatson: also pure python solution is easy to build on top of zipfiles [11:38] cjwatson: have you thought about delta updates [11:38] cjwatson: on the desktop that's not used in practice (in ubuntu at least) [11:38] don't really care about random access and pure python solution is easy either way [11:38] cjwatson: but on the mobile with lots of data vs little code it might be essential [11:38] cjwatson: well, zip's do both [11:39] zips [11:39] (tarfile is built into the python stdlib and writing ar is ~100 lines) [11:39] cjwatson: ar is not [11:39] cjwatson: well yeah [11:39] it's trivial [11:39] cjwatson: I know, had to do it too [11:40] cjwatson: still, what is the value of looking like a deb? [11:40] cjwatson: that dpkg -i can (perhaps) install it? [11:40] cjwatson: it will probably bork unless you also plan to ship DEBIAN in each package [11:40] more that it reduces impedance mismatch with other tools we already have [11:40] I have deliberately arranged that dpkg -i will refuse, but you can use dpkg -c and so on [11:41] cjwatson: so what existing tools would be able to work with the new-format packages? [11:41] I don't think the container format is really a desperately big deal either way [11:41] honestly [11:41] cjwatson: it might be, it really depends on where it is used [11:41] cjwatson: delta updates, store indexing, etc [11:42] it just meant I got to use dpkg to unpack and that means that if we need to do things like in-place upgrade in the future then it's a trivial matter rather than having to write a bunch of new very delicate package management code [11:42] cjwatson: it's not a deal-braker but a good format definitely helps [11:42] I trust dpkg for that kind of thing way more than anything I might write [11:42] i created a lunar clock in python. I want to add it to Ubuntu Unity taskbar. How 2 do? [11:42] cjwatson: dpkg supports in-place upgrades? [11:42] er, kind of obviously [11:42] cjwatson: IIRC it still unpacks stuff on the side [11:43] cjwatson: then replaces === salem_ is now known as _salem [11:43] cjwatson: that's not in-place [11:43] no, I mean in-place as opposed to click-package's current intended model of unpacking each version in a totally separate directory and re-symlinking [11:43] cjwatson: you can run out of space [11:43] cjwatson: ah [11:43] cjwatson: I see [11:43] cjwatson: I think that dpkg is too crazy for that, eg, all the failure modes, package states [11:43] makara, #ubuntu-app-devel for Ubuntu application development :) [11:43] you're mistaken; basically all the failure modes there relate to maintainer scripts [11:44] cjwatson: and all the integrity in dpkg, if you drop all the package states, is just fsync [11:44] nonsense [11:44] cjwatson: yes [11:44] cjwatson: but maintainer scripts cause all the package states [11:44] cjwatson: otherwise there would be none [11:44] dpkg had excellent integrity for many years before it started being forced to use fsync by hostile filesystem implementations [11:44] fsync is a red herring [11:44] cjwatson: after all, in the end you just unpack the container into the filesystem [11:45] cjwatson: done, ditto [11:45] you also need to keep track of which files to clean up afterwards, you still need to do the rename-over-the-top anyway otherwise you can have problems with executables in flight, etc. all problems dpkg solved many years ago. [11:45] no point redoing any of that [11:45] hmm [11:45] clean up - maybe not - depends on how you structure [11:46] it's simply not a problem I'm interested in re-solving [11:46] rename-over-the-top - can you explain? [11:46] open(2) [11:46] ETXTBSY [11:46] pathname refers to an executable image which is currently being executed and write access was requested. [11:46] ah [11:46] interesting === _salem is now known as salem_ [11:46] I wasn't aware that existed [11:47] dpkg is correct about many things most people have had no need to think of :) [11:47] cjwatson: I was aware of some of the things dpkg was doing [11:47] cjwatson: but some of those are the fauls of the system design [11:47] cjwatson: and dpkg is still doing a non-solution [11:47] cjwatson: eg, ripping libraries / data underneath from an app [11:47] cjwatson: firefox updates [11:47] (can you press enter slightly less frequently? this is a bit overwhelming) [11:47] cjwatson: none of that _has to happen_ it just does because of what dpkg was designed to install [11:48] cjwatson: sorry, I guess I should get back to my usual work now [11:48] no, just having trouble keeping up :) [11:50] so, you either do what dpkg does, or you have problems with ETXTBSY, or you end up with intermediate states where files are only half-written (IME one of the worst possible outcomes), or you unpack into completely separate directories and avoid all those problems at the cost of a bunch more space at least transiently - all the options have their problems [11:51] the only two viable ones IMO are completely-separate-directories and what dpkg does, and I'd like to leave the door open to having the choice between them in future, because dpkg's approach is likely to be better than completely-separate-directories for very large apps [11:51] cjwatson: I see your point [11:51] cjwatson: I suspect that a higher-level solution is needed though [11:51] (well, OK, it's probably also possible to have a mess of special cases where e.g. you defer removing files, but I would prefer not to go there if possible) [11:51] cjwatson: eg, telling app to stop for update, ensuring it really is, doing some in-place update from partial download, etc [11:53] cjwatson: full-copy app update is probably going to be cost prohibitive, you'd have to write O(N) bytes for each O(1) change, flash burns out [11:53] That kind of thing makes sense in a phone model; not sure it's good for convergence later [11:54] I do want to do delta updates, but it won't make the first cut. The main thing we need to ensure up front is just that we're using something like an rsync-friendly compression method in case we want to go that route [11:55] Which reminds me, is it possible to do an equivalent of gzip --rsyncable in Python directly or do I need to use a gzip subprocess? [11:55] cjwatson: I'm not sure, I never needed to do that. I suspect yes but manually by creating separate blocks on rsync boundary [11:56] cjwatson: but I suspect that rsync won't really be what you want to do in the end, code updates are not costly, assets are, and those are replaced, you only want to compress and send the files that are being changed. Trying to do in-file delta updates feels like a waste of effort, especially if it entails rebuilding a full package to install, locally [11:57] cjwatson: my point being that you probably want to ensure that you can send an efficient representation of ver-to-ver change and install _that_ rather than trying to rebuild the package locally [11:58] cjwatson: even if you really rsync a package from a remote server having that same package installed [11:58] Indeed. Given I'm using deb I suspect I might find that debdelta is a pretty close approximation of what I want [11:58] cjwatson: debdelta rebuilds debs locally, doesn't it?" [11:58] I'm not sure that's required, but haven't really looked yet === greyback is now known as greyback|lunch [11:59] cjwatson: so I do see a lot of value for research on top of dpkg, I'm still sceptical if that's the right choice in the end, the same as with other existing systems, it may just be not close enough after all the requirements are assembled [11:59] * zyga needs to switch to another topic [12:00] cjwatson: sorry for taking that much of your time, I'll see you at the vUDS :-) [12:00] Partly I will admit that I wanted to demonstrate that most of the performance and reliability problems with dpkg are not inherent === tsimpson_ is now known as tsimpson === d1b_ is now known as d1b === greyback|lunch is now known as greyback === Zic_ is now known as Zic [12:46] xnox: ed can be synced, I think? === cyphermox_ is now known as cyphermox [13:33] infinity: question, have you started with the bionic based armel cross toolchain? === tkamppeter_ is now known as tkamppeter === dholbach_ is now known as dholbach === achiang` is now known as achiang === iulian_ is now known as iulian === francisco is now known as Guest70796 === kentb-out is now known as kentb [15:25] slangasek: replied to bug 1177828 [15:25] bug 1177828 in systemd (Ubuntu) "no ACL set for USB sound device after upgrade to saucy" [Undecided,New] https://launchpad.net/bugs/1177828 [15:25] pitti: thanks [15:26] pitti: FWIW, I seem to be getting the same kind of problem here after suspend/resume [15:26] stgraber: missing ACLs? for what kind of dev? [15:26] pitti: I have working sound before suspending and no sound after resuming. Pulse still lists the soundcard but no sound comes out. Restarting pulse only gets me a dummy output. [15:27] oh, fun [15:27] stgraber: this is an internal sound card, or also USB? [15:27] pitti: internal [15:27] stgraber: again, udevadm info --export-db output would be helpful (if possible, before/after suspend) [15:30] sergiusens: Haven't started looking at it yet. I've been dead with some sort of ubuflu since the sprint. [15:30] pitti: gah, can't reproduce the bug anymore... just did a couple of suspend/resume and the ACLs are fine and sound works... [15:31] infinity: ack, no problem, just wanting to organize my work :-) [15:32] oh, actually, could have been something else as I remember that I rebooted the machine to fix it (had a call so didn't have much time to figure it out) and noticed that my user wasn't allowed to reboot the machine (dropping back to lightdm instead), so maybe it was something wrong with logind then... [15:32] I might have botched the uaccess backport in udev in some way [15:33] stgraber: that sounds like "no foreground session" indeed [15:34] slangasek: actually, it seems I get no ACLs on my scanner when plugging it in; that might be the same problem; the device has the "uaccess" tag, but doesn't get an ACL [15:35] I guess it's time to bite the bullet and upgrade to current udev [15:35] (the main obstacle is that we accumulated a set of patches which are nontrivial to forward-port as they have very little explanation and have never been forwarded upstream either) [15:36] but as an intermediate step I might just put it into a PPA without these [15:36] I don't see how that's a useful intermediate step. [15:36] for re-testing this bug [15:36] I'm certainly not going to run a udev that drops the distro patches on the floor [15:37] not all of them of course, mostly just avoid-exit-deadlock-for-dm_cookie.patch and avoid-exit-deadlock-for-timely-events [15:38] yeah, those are absolutely not patches I'm going to be running without [15:38] I fully expect I would hit those deadlocks if I did [15:42] ok, your udevadm output looks like my scanner situation - uaccess tag set, but no ACL applied [15:42] slangasek: howdy! I wanted to check with you how likely is this to be approved for SRU? We need celery in main for the MAAS SRU (precise), and in Quantal, we needed to drop the dependency. https://launchpad.net/ubuntu/+source/celery/2.5.3-1ubuntu1 [15:44] cjwatson: I'd like to resync the debian and ubuntu parted packages... would you sponsor an upload to debian, and if so, what format would you like it in? a git patch against the debian git repo I assume? [15:46] roaksoax: I'm not sure I understand the question. Are you proposing pushing that same version of celery from quantal to precise? [15:46] * pitti waves good night, see you on Friday (public holiday tomorrow) [15:46] slangasek: Sorry, not the same version, just the same patch we applied to celery in quantal [15:46] slangasek: so I want to SRU this: http://launchpadlibrarian.net/109389843/celery_2.5.3-1_2.5.3-1ubuntu1.diff.gz [15:47] psusi: some kind of git patches or git bundle or something, yeah [15:48] cjwatson: should I break it into one commit per patch then instead of just one big merge of all ubuntu patches? [15:48] roaksoax: the purpose of this is to remove the out-of-main build-dep on celery, so it can be moved to main in precise-updates to enable maas to use it in precise? [15:48] slangasek: yes [15:48] psusi: Yes please [15:49] With updated justifications in patch headers where necessary [15:49] roaksoax: and this change is needed for the maas SRU that's already been done, or for another upcoming one? [15:49] ok... then bundle it will be [15:49] slangasek: for the MAAS SRU (it hasn't yet been released) [15:50] roaksoax: yes, I'll accept that change [15:50] slangasek: ok awesome! I'll get it done then! Thanks! [15:57] In Ubuntu 13.04 hardening is not enabled for LibreOfffice package. Any ideas why? [15:58] Debian seems to have hardening support in LibreOffice package [16:00] Sweetsha1k: ^- [16:07] slangasek: Uploaded to precise-proposed! Thanks again! [16:07] what is the output of "dpkg-buildflags --get CPPFLAGS" on Ubuntu 13.04 AMD64 system? [16:11] halfie: -D_FORTIFY_SOURCE=2 - same as on Debian (wheezy or sid) [16:16] cjwatson, I am talking about PIE and RELRO options [16:16] cjwatson, ohh I see. thanks! [16:17] cjwatson, would you happen to know if PIE and RELRO are enabled in Debian's LibreOffice? [16:17] those are in CFLAGS. I think you may be seeing a change made by the Debian maintainer that became visible to you in Ubuntu first [16:17] no [16:17] but the revision history kind of suggests the explanation above ... [16:17]