| === PRaXiS is now known as MaGiSTeR | ||
| quidnunc | How do I access packages merged from debian? | 01:58 |
|---|---|---|
| JanC | define "access" | 02:04 |
| pitti | Good morning | 04:42 |
| pitti | infinity: denneed02 is unreachable (at least via apache) for about 3 days now; it's active and building in https://launchpad.net/builders though | 04:49 |
| pitti | infinity: does apache need some prodding there? otherwise we'll lose ppc ddebs | 04:49 |
| infinity | pitti: Erk, really? | 04:49 |
| * infinity looks. | 04:49 | |
| infinity | pitti: So, it seems angry building wine, and has been for 17h. But that doesn't account for the previous two days you say you couldn't reach it... | 04:51 |
| pitti | infinity: well, I got a metric ton of cron warning mails; let me look when they started | 04:51 |
| infinity | pitti: Should be reachable now? | 04:52 |
| pitti | infinity: ok, only since yesterday, sorry | 04:52 |
| pitti | infinity: confirmed, works again; thanks | 04:53 |
| * pitti mops them up | 04:53 | |
| infinity | pitti: Do you have any prototype for how you plan to populate ddebs.u.c from the librarian once we make the switch? | 04:54 |
| infinity | pitti: The time is drawing nearer, finally. | 04:54 |
| pitti | infinity: no, I don't; if we have the ddebs in LP but need to do the publishing on ddebs.u.c with ddeb-retriever, this will once again mean some rewrite | 04:55 |
| pitti | but at least it'll get massively simpler | 04:56 |
| infinity | pitti: Well, we still want the apt-gettable archive, I think, and putting in a second publisher instance to create ddebs.u.c, while perhaps the ultimate goal, won't happen right away. | 04:56 |
| infinity | pitti: But I think it should be as simple as walking all the Packages files, backtracking to the source:version tuple that produced the binaries, then gathering the ddebs from the API. | 04:56 |
| pitti | right | 04:57 |
| pitti | as opposed to now, where I have to do this crazy queueing, and try to match a ddeb to a release/pocket/component/source | 04:57 |
| infinity | pitti: Really not sure how we'll manage the publishing with a real publisher thing, when all our current content isn't in LP. Though, I guess the publisher doesn't actually ever remove files from disk that it doesn't know about. | 04:58 |
| infinity | pitti: So, maybe we could just start publishing in the middle of your populated archive, and it would Just Work. | 04:58 |
| infinity | (And we'd have to manually clean out pool when we retire old series') | 04:58 |
| infinity | wgrant: Would that work? | 04:59 |
| infinity | wgrant: I mean, assuming other things, like having a parallel publisher for ddebs will work at all. :P | 04:59 |
| pitti | infinity: I think this will become incrementally easier over time; after a full release or so we can rebuild everything which hasn't been rebuilt since then, and then LP has a full set of ddebs to publish | 05:00 |
| infinity | pitti: Sure, at some point, we can just decide the past doesn't matter, but that point isn't for a long time. | 05:00 |
| infinity | pitti: Because trusty. | 05:00 |
| pitti | unless we can import the current ddebs somehow? | 05:00 |
| infinity | pitti: We've talked about that, and every "solution" seemed crazier than the last. | 05:01 |
| wgrant | infinity: They also wouldn't be in indices... | 05:01 |
| infinity | pitti: But it's not beyond the realm of possibility to staple the ddebs onto existing build records. | 05:01 |
| wgrant | Yes it is. | 05:01 |
| infinity | wgrant: No, not beyond the realm of "possibility", just also crazy, see above. :P | 05:02 |
| pitti | well, otherwise we'll just have to wait until trusty goes away, and keep the ddeb-retriever thing until then | 05:02 |
| infinity | pitti: We can ditch ddeb-retriever as soon as we can publish LP ddebs in the middle of your archive. | 05:02 |
| wgrant | Well, no | 05:02 |
| pitti | or that | 05:02 |
| wgrant | It'll still have to sort of exist | 05:02 |
| wgrant | Something has to download them from LP | 05:03 |
| wgrant | It'll just be about 1000x less awful. | 05:03 |
| infinity | wgrant: So, yeah, backscroll. | 05:03 |
| wgrant | I'm currently trying to get my desktop to boot. Backscroll comes later :P | 05:03 |
| infinity | wgrant: We started with "let's fix ddeb-retriever to pull from API backrefs to the librarian". | 05:03 |
| infinity | wgrant: And then I moved on to "wait, a parallel publisher wouldn't in any way damage the files already on disk, cause it literally cares nothing for files it knows nothing about, so we COULD just publish ddebs in the middle of pitti's archive". | 05:04 |
| infinity | wgrant: And skip ddeb-retriever entirely. | 05:04 |
| infinity | wgrant: Assuming a parallel publisher is doable at all. | 05:04 |
| wgrant | LP will not be able to publish ddebs.ubuntu.com without significant work. | 05:04 |
| infinity | wgrant: Right, so that's a "next phase" thing, and a simpler ddeb-retriever is phase 1. | 05:04 |
| wgrant | And anything LP publishes might have external ddebs in the pool, but they wouldn't be able to be in indices. | 05:04 |
| pitti | the publishing is actually the most painful part, as it takes about 2 hours, or more than 24 if I remove the cache (which I need to do from time to time once publishing time hits the 6 h mark or so) | 05:05 |
| infinity | pitti: Some of us have some experience that might be able to help speed that up. | 05:05 |
| infinity | pitti: ddeb-retriever scares the poop out of me, but if we reduced it to the 20 lines or so probably required to parse Packages, backtrack, find API ref for ddebs, pull to disk, then it'll suddenly be something I'd be happy to contribute to. :P | 05:06 |
| infinity | pitti: Perhaps we could prototype on a parallel miniddebs archive that's using a PPA w/ ddebs as its source. | 05:07 |
| pitti | infinity: scares> heh, same; it's half of a soyuz implementation, and a really bad one | 05:07 |
| infinity | Doing the backref hunting via lplib instead of direct SQL will probably be slow as heck, but I imagine that won't matter much if we're not averaging more than a few thousand files per run. | 05:09 |
| pitti | yeah, that too | 05:09 |
| pitti | and we have to do it once per every other hour or so | 05:09 |
| infinity | Once per ftpmaster pulse, ideally. | 05:10 |
| pitti | we can probably iterate over the builds since the last time, and keep track of when the last run happened | 05:10 |
| infinity | When we get it working and proven-not-crap, we'll trigger it from the publisher. | 05:10 |
| pitti | that should only iterate over the recent builds | 05:10 |
| pitti | infinity: too slow | 05:10 |
| wgrant | Trigger, not blokc. | 05:10 |
| pitti | apt-ftparchive is excruciatingly slow | 05:10 |
| infinity | ^ | 05:10 |
| infinity | pitti: It shouldn't be. You're using it wrong. :) | 05:11 |
| infinity | pitti: We'll fix that. | 05:11 |
| wgrant | Particularly since you're not publishing sources. | 05:11 |
| wgrant | Binary publishing is really quick when you have it set up right. | 05:11 |
| infinity | pitti: Or, it's decided that ddebs aren't debs and it's not caching them properly, which would be a 1-char fix somewhere. | 05:11 |
| wgrant | It only took us 7 years to get there, too. | 05:11 |
| pitti | infinity: it does cache them in the big db; as I said, if I remove that it takes > 24 hours to run dpkg/tar on all of them | 05:12 |
| infinity | Of course, ddebs are bigger than debs, and thus slower to hash, but whatever. The fact that ddeb-retriever has otherwise slightly less work to do than frpmaster should balance that out. | 05:12 |
| pitti | yeah, any hint how to make it faster would be greatly appreciated | 05:12 |
| infinity | pitti: I'm confident we can find he bottlenecks and stomp them out. | 05:12 |
| infinity | pitti: But let's start with prototyping the new/slim variant againt a ddeb-publishing PPA, and go from there. | 05:13 |
| infinity | pitti: So I have a codebase to work with that doesn't make me want to stab my eyes out and mail them to Germany. | 05:13 |
| pitti | heh | 05:13 |
| pitti | (brb) | 05:13 |
| infinity | wgrant: Do the trigger points in the publisher have knowledge of which pockets were dirty? | 05:14 |
| infinity | wgrant: I'm guessing no, but that could be passed in the env, perhaps? | 05:14 |
| wgrant | infinity: I think so. | 05:14 |
| wgrant | But if not, we can tell them, | 05:14 |
| infinity | Maybe not needed for this, I guess, I could just cmp old and new Packages before deciding who needs a-f love. | 05:14 |
| infinity | But in general, might be handy to pass along if it's not. | 05:14 |
| wgrant | Oh | 05:15 |
| wgrant | X randomly started after 150 seconds. | 05:15 |
| wgrant | I guess that... works. | 05:15 |
| infinity | Is this your way of telling me not to reboot today? | 05:17 |
| wgrant | I just upgraded my nvidia-plagued desktop to vivid | 05:17 |
| wgrant | It's running nvidia-343 from xorg-edgers. | 05:18 |
| wgrant | So it's a bit of a special case. | 05:18 |
| infinity | Ahh. | 05:18 |
| infinity | Right, I'm going to get an early night tonight and see if this strange feeling of enthusiasm carries forward to Monday morning. | 05:21 |
| infinity | pitti: Let's revisit this in a week or two and see what we can come up with for a prototype that won't suck when the ddeb world improves. | 05:22 |
| pitti | infinity: yeah; for that it would be good to actually have some ddebs somewhere in LP to try this on | 05:23 |
| infinity | pitti: Easily done in a PPA, like I said. | 05:23 |
| pitti | but I figure this will use something like getPackageUploads(created_since_date=last_run) | 05:23 |
| pitti | and custom_type='raw-ddeb' or similar | 05:24 |
| pitti | so that we only process the recent uploads, not the entire archive | 05:24 |
| infinity | pitti: I'd rather have it match the Packages files we mirror from ftpmaster identically, so no need for date windowing. | 05:24 |
| infinity | pitti: Rather, we'll just be processing deltas from last run to current. | 05:24 |
| pitti | infinity: that's quite a lot more bookkeeping then, though? | 05:24 |
| pitti | yes, we still need to match them up against the archive's Packages.gz of course | 05:25 |
| infinity | pitti: Shouldn't be too bad. | 05:25 |
| wgrant | pitti: ddebs aren't actually custom uploads. They have BPPHs, but they just don't hit disk. | 05:26 |
| pitti | for now I think we can only rip out the wgetting of http://*.buildd/ and replace that with getPackageUploads(created_since_date=last_run) | 05:26 |
| wgrant | So you'd basically want to look up the SPPHs that you have, call getBuiltBinaries(), and then filter to ddebs. | 05:26 |
| pitti | I think that ridiculously involved matching against the archive's Packages.gz needs to stay | 05:26 |
| pitti | wgrant: but still from getPackageUploads(created_since_date=)? | 05:26 |
| wgrant | Or watch new entries in getPublishedBinaries, but I'm not sure how GC for that would work on your end. | 05:26 |
| wgrant | Right, that could work too. | 05:27 |
| wgrant | There are a few approaches, but it's not like raw-static-translations. | 05:27 |
| pitti | I just can't query all packages in all releases all the time | 05:27 |
| infinity | No, but we can keep local state. | 05:27 |
| pitti | that's like three magnitudes too slow | 05:27 |
| infinity | So if we walk Packages, then only query things we've never queried before, we're getting the delta. | 05:27 |
| infinity | Then GC stuff that's no longer referenced. | 05:28 |
| wgrant | Personally, I would watch the Packages files, and keep a local map of (source, version) -> [ddebs] | 05:28 |
| infinity | Then run a-f with a file list generated from the above steps. | 05:28 |
| wgrant | When you see a source version drop out of all the Packages files, you drop those ddebs. | 05:28 |
| wgrant | When you see a new one appear, you query for which ddebs it should have and download them. | 05:28 |
| infinity | wgrant: I think we just said more or less the same thing. :) | 05:28 |
| pitti | wgrant: that's what ddeb-retriever more or less does | 05:28 |
| wgrant | Probably. I wasn't listening to you :P | 05:28 |
| infinity | Typical. | 05:28 |
| infinity | Kids these days. | 05:28 |
| pitti | it downloads all Packages.gz and builds a packagename -> pocket -> version -> arch -> component map (this takes some 20 mins already) | 05:29 |
| wgrant | pitti: Right, except now you can ask LP for the map, rather than having to do the hilarious madness with guessing which ddeb filenames map to what after you download them from the backdoor :) | 05:29 |
| wgrant | Hmm. | 05:29 |
| wgrant | That really shouldn't take more than 5 seconds. | 05:29 |
| wgrant | Unless germanium is secretly a 6502. | 05:29 |
| wgrant | That would explain a lot, actually. | 05:29 |
| infinity | germanium's decently speedy. | 05:29 |
| pitti | and then match ddebs against that mapping | 05:29 |
| pitti | I hope that can get massively simpler, if I can get the proper releases/versions/components etc. from LP | 05:30 |
| wgrant | Anyway, we should indeed find an appropriately configured PPA and fix the temporary, short-term, 8 year solution to work for another 8 years :) | 05:30 |
| pitti | right now, the downloaded tarballs tell me just about nothing | 05:30 |
| pitti | heh | 05:30 |
| wgrant | Right. | 05:30 |
| wgrant | LP can get you the map from source -> ddebs, and we might even want to add a new API call or two to make that easier if it proves too slow. | 05:30 |
| wgrant | No more guessing from tarball contents. | 05:31 |
| wgrant | The main problem for you is working out which sets of ddebs you want. | 05:31 |
| wgrant | And that should be easy to calculate from the Packages files. | 05:31 |
| pitti | yes | 05:31 |
| pitti | and then of course building the lists for a-f and calling that, which takes effing log (but is conceptually easy) | 05:32 |
| infinity | Building the lists should be near instant if we do it right with some local intelligence and caching. | 05:33 |
| infinity | a-f runs might be slower than peop, cause germanium's not actually as fast as I remember. :P | 05:33 |
| infinity | But we'll work that out. A big lock around the whole thing so it can take longer than ftpmaster and skip a run here and there should make it good enough. | 05:33 |
| wgrant | a-f should take less than 15 seconds per DAS when configured correctly, I suspect. | 05:33 |
| wgrant | Even on germanium. | 05:33 |
| pitti | 42.5 MB/s read speed | 05:33 |
| pitti | (on germanium's disk) | 05:33 |
| wgrant | It's seek speed and a-f cache maintenance that's the bigger concern. | 05:34 |
| pitti | yeah | 05:34 |
| wgrant | Unless you keep your a-f cache clean, you are basically dead. | 05:34 |
| wgrant | As we discovered 18 months ago. | 05:34 |
| infinity | All tractable. | 05:34 |
| pitti | wgrant: yeah, I don't know the secret recipe to do that | 05:34 |
| infinity | As we discovered from the FEATURE CELSO IMPLEMENTED SIX YEARS AGO AND FORGOT TO TELL ANYONE ABOUT. | 05:34 |
| wgrant | We have the power. | 05:34 |
| pitti | wgrant: I just drop the db from time to time, take the "runs for 30 hours" hit, and go on | 05:34 |
| infinity | Not that I'm bitter. | 05:34 |
| wgrant | Heh | 05:34 |
| wgrant | Yeah, that's what we used to do. | 05:34 |
| pitti | 15.6 MB/s write speed on germanium | 05:35 |
| pitti | that's really not great | 05:35 |
| pitti | and that was a linear cp of an 843 MB file | 05:35 |
| wgrant | Now we run a daily cronjob which removes files that no longer exist in the pool. | 05:35 |
| pitti | so I don't know how much it sucks on random access | 05:35 |
| wgrant | And keeps the cache snappy. | 05:35 |
| infinity | wgrant: Actually just triggered on a timer from the publisher itself, but whatever. | 05:35 |
| pitti | wgrant: you mean remove from the db? | 05:35 |
| wgrant | pitti: Right. | 05:35 |
| wgrant | So the DB doesn't grow without bound. | 05:35 |
| wgrant | infinity: Well yeah, but effectively. | 05:35 |
| infinity | Important difference, cause racing those caches with an external job could have dire consequences. | 05:36 |
| infinity | Or just fail entirely if a-f actually uses proper BDB locking. | 05:36 |
| infinity | Pick one. | 05:36 |
| wgrant | Dire consequences are the spice of life. | 05:36 |
| infinity | If germanium really is too slow for this, one might ask IS nicely to slap germanium's array on a newer machine. | 05:37 |
| infinity | But I don't think it'll limit us when we get it set up right. | 05:37 |
| wgrant | Agreed. | 05:38 |
| infinity | Bed for realz. | 05:38 |
| wgrant | Night. | 05:38 |
| pitti | sleep well | 05:38 |
| infinity | ... my Firefox just decided I'm Arabic. | 06:10 |
| infinity | Oh, no. Not Arabic. But some language I don't read that goes right to left. | 06:11 |
| infinity | Oh, yes. Arabic indeed. | 06:11 |
| infinity | So confused. | 06:12 |
| pitti | mvo: guten Morgen | 07:48 |
| pitti | mvo: do you know if there's a fix for apt's test suite regression with the new dpkg? | 07:48 |
| mvo | pitti: I don't think so, did I miss a mail from autopkgtest? | 07:49 |
| pitti | mvo: notifications aren't back on (will do with jibel today), so falling back to "pitti annoys people on IRC" | 07:50 |
| pitti | mvo: https://jenkins.qa.ubuntu.com/job/vivid-adt-apt/? | 07:50 |
| mvo | pitti: heh :) ok | 07:50 |
| pitti | mvo: might be fixed in Debian git already, as dpkg has been there for a while | 07:51 |
| mvo | pitti: right | 07:52 |
| mvo | pitti: I will take care of it | 07:53 |
| pitti | mvo: danke! | 07:53 |
| pitti | utlemming: I tested http://cloud-images.ubuntu.com/vivid/20141031.4/ amd64, working well; thanks! | 08:14 |
| pitti | utlemming: I suppose /current will appear once this gets cron'ed? | 08:14 |
| seb128 | Noskcaj, pitti: since that gsettings-desktop-schemas changed some default value, do we override for e.g "button-layout" in ubuntu-settings to avoid regressions/behaviour change on upgrade? | 08:47 |
| seb128 | same for "action-middle-click-titlebar" | 08:47 |
| seb128 | do we need override* | 08:48 |
| pitti | mvo: "Jenkins Fixed - vivid-adt-apt 7" -- cheers! | 08:52 |
| pitti | bonjour seb128 | 08:52 |
| seb128 | pitti, salut, ça va bien ? | 08:52 |
| pitti | seb128: sorry, I didn't notice a change in the general desktop or control center | 08:52 |
| pitti | what changed? | 08:52 |
| seb128 | pitti, did you restart unity? is middle click on the title bar still doing minimize? | 08:53 |
| pitti | seb128: oui, alors j'ai me levé à 3 h :/ | 08:53 |
| seb128 | :-( | 08:53 |
| pitti | I tried in a guest session and an existing user, but I didn't try title bar clicking; hang on | 08:53 |
| pitti | seb128: that maximizes/unmaximizes a window; is that different than before? | 08:54 |
| pitti | (not minimize) | 08:54 |
| seb128 | pitti, well, I just read the diff | 08:54 |
| seb128 | http://launchpadlibrarian.net/188976878/gsettings-desktop-schemas_3.12.2-0ubuntu1_3.14.1-1ubuntu1.diff.gz | 08:54 |
| seb128 | <key name="button-layout" type="s"> | 08:55 |
| seb128 | - <default>':minimize,maximize,close'</default> | 08:55 |
| seb128 | + <default>'appmenu:close'</default> | 08:55 |
| seb128 | <key name="action-middle-click-titlebar" | 08:55 |
| seb128 | enum="org.gnome.desktop.GDesktopTitlebarAction"> | 08:55 |
| seb128 | - <default>'lower'</default> | 08:55 |
| seb128 | + <default>'none'</default> | 08:55 |
| seb128 | pitti, ^ | 08:55 |
| mvo | pitti: your welcome | 08:55 |
| seb128 | so it seems like it's going to create behaviour changes, we might need to add those back in our ubuntu-settings override | 08:55 |
| pitti | seb128: yeah, but I figure the Ubuntu theme or so overrides this; I didn't check where that happens, just that it happens | 08:56 |
| seb128 | pitti, ok,I didn't get the update, it looks in theory that middle click on the wm decoration should stop minimizing after that update | 09:00 |
| seb128 | but maybe compiz has some override in some way | 09:00 |
| seb128 | I'm going to check later when I get the update | 09:00 |
| LocutusOfBorg1 | hi developers, have a nice week! | 09:53 |
| cjwatson | pitti: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/archivepublisher/model/ftparchive.py cleanCaches has the magic you need. It should be pretty easy to stitch that in right now, independent of any other work. | 10:13 |
| pitti | cjwatson: thanks! | 10:38 |
| === _salem is now known as salem_ | ||
| roaksoax | /wi/win 9 | 11:50 |
| === MacSlow is now known as MacSlow|lunch | ||
| === timrc-afk is now known as timrc | ||
| saladim | some help in understanding schroot and sbuild needed plz | 13:22 |
| saladim | i always get errors using sbuild 'Permission denied', 'could not clean source directory' with sbuild | 13:23 |
| saladim | have setup btrfs-snapshot schroot, to which i can login and do things | 13:23 |
| === MacSlow|lunch is now known as MacSlow | ||
| === salem_ is now known as _salem | ||
| xnox | mdeslaur: may i package gpgme to provide one library for gpg2 and one for gpg1, conflicting with each other? also what needs to be done to get gpg2 by default on the desktop? | 14:29 |
| xnox | gtk3 pinentry? | 14:29 |
| mdeslaur | xnox: I know nothing about gpgme, so I'm not the one to ask, sorry | 14:31 |
| mdeslaur | xnox: as for gpg2, I thought the problem was that it required an agent to work, and that was an issue | 14:31 |
| xnox | mdeslaur: so was it not you who uploaded https://launchpad.net/ubuntu/+source/gpgme1.0/1.5.1-6ubuntu1 ? | 14:32 |
| mdeslaur | xnox: yes, because i TIL for a security update | 14:32 |
| mdeslaur | xnox: but I'm knowledgeable about it | 14:33 |
| mdeslaur | s/I'm/I'm not/ | 14:33 |
| xnox | mdeslaur: we ship an agent by default - gnome-keyring one, which doesn't support everything that gpg2 needs however. we'd need a change of the default agent. | 14:33 |
| xnox | mdeslaur: ok. | 14:33 |
| mdeslaur | xnox: and we'd start an agent by default on the server? | 14:33 |
| xnox | mdeslaur: on the server, gnupg fallsback to forking tty agent by itself. | 14:34 |
| LocutusOfBorg1 | Laney, did you upload -v3 for gdcm? | 14:47 |
| LocutusOfBorg1 | seems so, wonderful | 14:48 |
| LocutusOfBorg1 | thanks | 14:48 |
| LocutusOfBorg1 | thanks, I can ping you if it gets accepted (and published, to avoid other rebuilds) | 14:49 |
| Laney | np | 14:58 |
| === Sweetsha1k is now known as Sweetshark | ||
| === _salem is now known as salem_ | ||
| === Pici is now known as to | ||
| === to is now known as Pici | ||
| pitti | hallyn, stgraber: hmm @ https://jenkins.qa.ubuntu.com/job/vivid-adt-lxc/7/ARCH=i386,label=adt/console -- did anything in cgmanager recently change wrt. the cgroup controllers? | 15:29 |
| hallyn | pitti: yeah, cgmanager 0.33 has an updated api, which lxc uses - and uses wrongly. there is a fix in upstream lxc, but i guess it needs to go into vivid | 15:30 |
| pitti | there surely is bug 1346734, but we don't run systemd in vivid yet by default | 15:30 |
| ubottu | bug 1346734 in systemd (Ubuntu) "Unprivileged LXC containers don't work under systemd" [Medium,Triaged] https://launchpad.net/bugs/1346734 | 15:30 |
| hallyn | no it's not that | 15:30 |
| pitti | hallyn: ah, splendid; so I can chalk this off as "understood/handled" | 15:30 |
| hallyn | it's that lxc tries to pass "all" to getpidcgroup | 15:30 |
| pitti | hallyn: thanks | 15:30 |
| hallyn | (which isn't suported) | 15:30 |
| hallyn | np. | 15:30 |
| hallyn | stgraber: ^ were you going to push a new lxc to vivid soonish? | 15:31 |
| stgraber | pitti: I'll upload a fix to vivid once upstream Ci is back online and I confirm the fix works | 15:31 |
| pitti | stgraber: merci | 15:31 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| brendand | bregma, omg are you going to implement https://bugs.launchpad.net/bugs/793482 ? | 16:08 |
| ubottu | Ubuntu bug 793482 in Compiz "[WISHLIST] Windows in global expose (Super+W) should have title underneath" [Low,Triaged] | 16:08 |
| bregma | brendand, hopefully at some point, but realistically "low" priority means we may suffer from the inevitable heat-death of the universe before we get to it | 16:09 |
| brendand | bregma, well it's only taken 3 years to be triaged | 16:15 |
| brendand | bregma, i can wait another 3 for it to be implemented :) | 16:16 |
| brendand | (or do it myself, yes i know) | 16:16 |
| brendand | patches welcome etc etc | 16:16 |
| bregma | brendand, I'm sure you can just whip something up in your spare time? | 16:17 |
| brendand | bregma, actually if i could get a hint or two about where to look... | 16:19 |
| hallyn | stgraber: pitti: I went ahead and pushed lxc with the attach regression fixed to vivid, as that's pretty high prio | 16:24 |
| bregma | brendand, I'd start in the Compiz source at plugins/expo/src/expo.cpp | 16:24 |
| pitti | hallyn: ah, great, thanks | 16:24 |
| brendand | bregma, and does that already have some visibility to the window objects (note i know nothing about compiz) | 16:25 |
| brendand | ? | 16:25 |
| brendand | bregma, so that i would just have to fish out the title of the window | 16:26 |
| gQuigs | anyone know how to get the whoopsie identifier for a user from the CL? | 16:29 |
| gQuigs | you can get it from the gui by going Dash -> Security & Privacy | Diagnostics -> Show Previous Error Reports | 16:29 |
| gQuigs | (you can get it using C like this- https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1319160/comments/2) | 16:29 |
| ubottu | Ubuntu bug 1319160 in sosreport (Ubuntu) "Collect /var/crash info or the users personal crash key" [Medium,Triaged] | 16:29 |
| bregma | brendand, I can't be certain the name is available without digging down through the code -- at which point the fix would become trivial | 16:30 |
| brendand | bregma, well you should find out soon :) | 16:32 |
| xnox | gQuigs: there is dbus api to query it. | 16:46 |
| xnox | gQuigs: gdbus call -y -d com.ubuntu.WhoopsiePreferences -o /com/ubuntu/WhoopsiePreferences -m com.ubuntu.WhoopsiePreferences.GetIdentifier | 16:49 |
| xnox | or similar with dbus-send | 16:49 |
| gQuigs | xnox: thanks! | 16:51 |
| bdmurray | xnox: you'd talked about a casper patch for /var/crash the other day. Is that something you could do or give me an idea about? | 17:23 |
| xnox | bdmurray: in a meeting atm. i'll respond later. | 17:30 |
| bdmurray | xnox: okay, thanks | 17:31 |
| xnox | bdmurray: i concluded that it works correctly already, by virtue that we had to disable whoopsie to get rid of the pop-ups. | 18:11 |
| xnox | bdmurray: if it was working, simply because we are crashing all over the place and the upload daemon starts after the first crash, then indeed this needs to be fixed in casper. | 18:11 |
| xnox | bdmurray: something simple like "touch /var/crash/.anyfile; rm /var/crash/.anyfile" after the overlay has been setup for the target. | 18:12 |
| xnox | this will create an inode & /var/crash directory in the overlay and then inotify will work for the whoopsie daemon. | 18:12 |
| xnox | bdmurray: i have not created a patch for this, but will be happy to review it if you write one. | 18:12 |
| bdmurray | xnox: so the overlay work is already done we just need to "initialize" it so inotify will work? | 18:14 |
| barry | @pilot in | 19:01 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry | ||
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| === timrc is now known as timrc-afk | ||
| === timrc-afk is now known as timrc | ||
| === salem_ is now known as _salem | ||
| barry | @pilot out | 22:40 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!