| === wedgwood is now known as wedgwood_away | ||
| m4n1sh | ev: I have made changes to privacy manager and need to integrate diagnostics too with it. IIRC prior to this, whoopsie package was not present. Now I can find libwhoopsie package and I am not able to figure out how whoopsie-generated.{c/h} is being generated in the current codebase | 00:31 |
|---|---|---|
| === Ursinha- is now known as Ursinha | ||
| === rsalveti_ is now known as rsalveti | ||
| === _salem is now known as salem_ | ||
| === rsalveti_ is now known as rsalveti | ||
| === Ursinha_ is now known as Ursinha | ||
| === Ursinha_ is now known as Ursinha | ||
| === LaserJock1 is now known as LaserJock | ||
| === salem_ is now known as _salem | ||
| slangasek | roaksoax: which release is this dist-upgrade happening in? | 02:53 |
| slangasek | roaksoax: ah, n/m, found at the bottom of your pastebin | 02:53 |
| slangasek | roaksoax: so, why are you using a Conflicts: against tftpd-hpa, instead of a Breaks:? | 02:54 |
| roaksoax | slangasek: cause i thought conflicts would be more rrstrictive | 02:55 |
| roaksoax | so both services dont run at the same time | 02:55 |
| roaksoax | slangasek: btw upgrade candidates can be found at ppa:maas-maintainers/stable | 02:56 |
| slangasek | roaksoax: Breaks: is sufficient to ensure that both packages aren't "installed" at the same time; let me refresh my memory (from policy) as to whether Breaks is actually a better choice here | 02:56 |
| slangasek | roaksoax: ok, I can't convince myself that Breaks: tftpd-hpa would be more correct than Conflicts:, so let's set that aside | 02:59 |
| slangasek | roaksoax: however, looking at the package that's in raring, the /other/ Conflicts (on maas (<= ...) and maas-region-controller (<= ...)) should almost certainly be Breaks rather than Conflicts, since they're paired with Replaces | 03:00 |
| roaksoax | slangasek: yeah i was thinking on changing that | 03:00 |
| slangasek | roaksoax: I don't know if changing those would be sufficient to make apt happy, but it would be an appropriate fix in its own right | 03:00 |
| roaksoax | slangasek: i tried taht and disnt make apt happy unfortunately | 03:00 |
| slangasek | ok | 03:01 |
| roaksoax | but i could give it another try | 03:01 |
| slangasek | is the 'cobbler' package installed in this scenario? | 03:01 |
| slangasek | Well, I guess maas-provision is more likely | 03:02 |
| roaksoax | slangasek: yeah maas-provision | 03:02 |
| slangasek | roaksoax: and maas-provision isn't built from maas source... so the current version of that package still has a Recommends: tftpd-hpa? | 03:03 |
| slangasek | this may be why apt considers it better to remove maas instead of removing tftpd-hpa | 03:03 |
| slangasek | sorry, dinner | 03:03 |
| roaksoax | slangasek: yes, so maas-provision is its own source package. And that indeed Recommends tftpd-hpa. I have tried conflict/replace and break/replace maas-provision in both 'maas' binary and 'maas-cluster-controller' binary, with no luck whatsoever | 03:06 |
| === Ursinha_ is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| hyperair | has anyone here used valgrind's memcheck tool successfully on any glib/gtk app? | 04:04 |
| hyperair | it always seems to have a ridiculous amount of rubbish from gtk/glib's internals | 04:04 |
| RAOF | There's a suppression file for that IIRC | 04:05 |
| codebrainz | only one I found was from really old wxWidgets wiki | 04:05 |
| hyperair | RAOF: iirc that was last updated in 2009. | 04:05 |
| codebrainz | hyperair, ask in #gtk on gimpnet :) | 04:05 |
| hyperair | heh | 04:07 |
| pitti | Godo morning | 06:08 |
| RAOF | pitti: Godot morning! | 06:13 |
| pitti | RAOF: hohow are yohoow? | 06:14 |
| pitti | slangasek: hey Steve, still here? | 06:16 |
| pitti | slangasek: do you have an opinion about mounting /sys/fs/cgroup in /lib/init/fstab? it would eliminiate race conditions and avoid modifying udev's and logind's udev rules (and even there it's a race condition) | 06:16 |
| === ewindisch_ is now known as ewindisch | ||
| === asac` is now known as asac | ||
| dholbach | good morning | 07:48 |
| === smb` is now known as smb | ||
| zyga | utlemming: hey | 09:07 |
| Whoopie | arges: Hi, regarding iptables, why haven't also fixed the debian-changes things as described by me in the bug report? Just curious. | 09:23 |
| xnox | mdeslaur: I am sorry about that =) i did think "i bet mdeslaur thinks openssl is his package only by now ;-)" | 09:29 |
| vibhav | hyperair: yes, I remember seeing a memory leak via a glib routine | 09:35 |
| Mirv | arges: could you accept/evaluate/sync systemtap 2.1 from Debian? bug #1130626 now has pbuilder log as well | 09:35 |
| ubottu | bug 1130626 in systemtap (Ubuntu) "Update Ringtail SystemTap to 2.1" [Undecided,New] https://launchpad.net/bugs/1130626 | 09:35 |
| hyperair | vibhav: did you use a suppresion file or anything? valgrind's output is typically pretty polluted when used on a glib program | 09:36 |
| vibhav | No | 09:36 |
| vibhav | hyperair: I will try one right now | 09:36 |
| vibhav | There are some glib routines which were leaking memory | 09:37 |
| vibhav | s/are/were/ | 09:37 |
| vibhav | hyperair: Is there a specific suppresion file? | 09:38 |
| hyperair | vibhav: nah, i was wondering if there was a suppresion file around, because the last time i used it on a glib application it was full of internal glib stuff | 09:38 |
| vibhav | Indeed | 09:39 |
| hyperair | oh interestingly it seems pretty clean now | 09:41 |
| hyperair | =O | 09:41 |
| hyperair | just some warninsgs from cairo | 09:42 |
| xnox | mdeslaur: you are free to upload your fix for openssl on top of my work and do -v'*2.2' to have all the bug references together. | 09:46 |
| xnox | mdeslaur: I was thinking of preparing precise upload for my two bugs as well. | 09:46 |
| infinity | xnox: Please do upload your openssl changes to precise as well, yes. | 10:08 |
| xnox | infinity: yeah, testing. | 10:08 |
| infinity | xnox: I won't be accepting the arm assembly thing until Rob gets me some solid evidece that it doesn't blow up the world, but he's promised me this. :P | 10:08 |
| * infinity goes back downstairs to ingest more beer. | 10:09 | |
| xnox | infinity: for quantal, yesterday I did run full testsuite & benchmarks on nexus7, all was fine. | 10:09 |
| xnox | infinity: repeating for precise now. | 10:09 |
| xnox | infinity: it's armv4 assembly from way back when ;-) | 10:09 |
| infinity | xnox: Can you do some realworld things like a local apache2 w/SSL and abuse it a bit to see if it DTRT? | 10:09 |
| xnox | infinity: i do wonder if the elliptic curves optimisations will work on arm64 as well =))))) | 10:10 |
| infinity | xnox: But yeah, I have no reason to believe the assembly doesn't work. Just that it's not been tested in Debian/Ubuntu ever. | 10:10 |
| xnox | infinity: well it was tested in raring =)))) | 10:10 |
| infinity | xnox: FSVO "tested". | 10:10 |
| xnox | =)))))))))))))) | 10:10 |
| infinity | xnox: We don't have that many people abusing openssl on ARM in raring, I suspect. | 10:10 |
| xnox | apart from hrw =) | 10:10 |
| pitti | xnox: for the list in https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration, did you grep the Ubuntu or only the Debian archive? | 10:15 |
| pitti | xnox: i. e. indicator-session is missing | 10:15 |
| pitti | (adding it now) | 10:15 |
| xnox | pitti: I did not finish the debian grep, jdstrand did launch ubuntu grep. Will take some time to get the results back. | 10:15 |
| pitti | ack | 10:16 |
| pitti | ah, it seems indicator-session tries the org.gnome.SessionManager first, and then fall back to CK | 10:16 |
| pitti | so fixing gnome-session ought to help actually; doing that now | 10:16 |
| Laney | I have a canonistack instance set up to try and get codesearch working for Ubuntu | 10:18 |
| Laney | but I haven't figured out how to work it yet; documentation is quite lacking | 10:18 |
| pitti | ah bummer, our gnome-session needs logind >= 183 | 10:18 |
| seb128 | Laney, it's easier to just do that from the datacenter | 10:18 |
| Laney | just do what? | 10:18 |
| seb128 | Laney, grep the archive | 10:19 |
| Laney | I'm talking about setting up http://codesearch.debian.net/ for Ubuntu | 10:19 |
| seb128 | oh, ok | 10:19 |
| * pitti used http://people.canonical.com/~pitti/scripts/for-srcarchive on lillypilly before (that has a local mirror) | 10:19 | |
| seb128 | right | 10:19 |
| seb128 | Laney, I though you wanted to do a one time grep, not to set up a service for those ;-) | 10:19 |
| seb128 | Laney, good luck | 10:19 |
| Laney | https://github.com/debiancodesearch/dcs/blob/master/README | 10:20 |
| Laney | not so detailed ;-) | 10:20 |
| Daviey | Laney: ISTR jodh was a fan of this aswell | 10:20 |
| Laney | excellent, it's a great service | 10:20 |
| Laney | I will get around to asking the developer for better instructions | 10:21 |
| Laney | actually I'll do it now while I'm thinking about it | 10:22 |
| mitya57 | tumbleweed: will you upload pyxdg? :) | 10:22 |
| jodh | Daviey/laney: I'm certainly a fan of such a facility but was originally looking at opengrok (which has a bunch of cool features); if the indexing can be partitioned, we could use juju to scale horizontally. | 10:25 |
| Daviey | jodh: You just sold it to me :) | 10:26 |
| Laney | yeah I'm not sure debiancodesearch has anything like that | 10:26 |
| jodh | Daviey: one of the advantages being that opengrok could not only index all the branches on lp, but it could also index the archives and extract meta-data out of the built packages themselves (with a few tweaks). | 10:28 |
| Daviey | Interesting. | 10:29 |
| Daviey | Whilst we are talking of developer resource tools, xnox - how is your snapshot equivalent thing going? :) | 10:29 |
| xnox | Daviey: submerged in the todo list =) | 10:30 |
| xnox | Daviey: I dunno, I should fix up my access to lcy02 (for some reason only lcy01 works for me at the moment) and I should really tinker with that. But you know lvm2 SRUs to verify.... =) I'm up for trading ;-) | 10:31 |
| Daviey | xnox: lcy01 and lcy02 run different versions of openstack.... what tooling are you using to converse with them.. maybe there is a bug? | 10:32 |
| xnox | Daviey: interesting. I'm using juju 0.6.0.1. | 10:33 |
| xnox | with openstack providers I believe. | 10:33 |
| Daviey | xnox: check in with hazmat, he might know the situation | 10:34 |
| xnox | Daviey: thanks. | 10:34 |
| Laney | what's the idea there? exposing the librarian somehow or running an actual snapshot equivalent? | 10:38 |
| xnox | Laney: something that does rsync of dists/, indexes the various archives by time. something else that will fetch and serve them. something third (nginx reverse proxy) that will in order try: local cache, archive.ubuntu.com, old-releases.ubuntu.com, launchpadlibrarian to actually serve the requested .dsc, *.tar.*, *.deb | 10:41 |
| Daviey | Laney: librarian... store valid Packages.gz as time snapshots, but proxy through to librarian AIUI | 10:41 |
| Daviey | right | 10:41 |
| Laney | then write a deb-bisect? :) | 10:43 |
| xnox | Laney: the interested parties can do that then, yes ;-) | 10:46 |
| * Daviey fains disinterest | 10:47 | |
| Laney | i suppose it would be apt-bisect | 10:48 |
| xnox | infinity: apache bench stress tests?! =) | 10:52 |
| pitti | slangasek: done, https://bugs.freedesktop.org/show_bug.cgi?id=62016 | 11:01 |
| ubottu | Freedesktop bug 62016 in daemon "pkexec does not apply PAM's environment" [Normal,New] | 11:01 |
| sonne | so will 13.04 have still amazon search enabled by default? | 11:08 |
| xnox | sonne: yeah. also see smart search blog post from Allen Bell about the improvements that are planned there. | 11:10 |
| xnox | sonne: this is more of a #ubuntu-desktop question though ;-) | 11:10 |
| sonne | xnox, alan? | 11:10 |
| sonne | i can't seem to be able to find the blog post you're mentioning *shrug* | 11:11 |
| sonne | thanks for answering my question though :) | 11:11 |
| xnox | sonne: http://www.theopensourcerer.com/2013/01/ubuntu-smart-scopes/ | 11:12 |
| sonne | cheers | 11:12 |
| davidcalle | xnox, sonne, this won't be in 13.04 though | 11:12 |
| davidcalle | xnox, sonne, this has been discussed during the UDS session about it two days ago. | 11:13 |
| sonne | that's too bad | 11:13 |
| davidcalle | sonne, I know :) | 11:13 |
| xnox | davidcalle: hehe =) i missed that session. Oh well. Or see latest UDS where things got redefined then ;-) | 11:14 |
| sonne | would have been a nice improvement for the search problem | 11:14 |
| sonne | i haven't really followed the discussions in the last months, but i know there has been a lot of drama about the search feature | 11:15 |
| davidcalle | sonne, indeed. I'm actually implementing most of the new search engines and I'm looking forward to being able to disable/enable them per theme and per data source. | 11:17 |
| sonne | davidcalle, personally i'd rather have the user decide whether or not to have searches on the internet on installation | 11:18 |
| sonne | or some kind of other solution that would not have the user go and google how to disable the searches | 11:19 |
| sonne | but then, i have no clue on how the whole thing is being handled :) | 11:19 |
| davidcalle | sonne, I don't know, I think that the settings > privacy > on/off switch is a good design. | 11:21 |
| davidcalle | sonne, in that regard, the Dash now advertises the fact that it's searching online "Search your computer and online sources" is in the search field default text (when the switch is ON) | 11:23 |
| sonne | maybe adding a "<Click here for options>" right there would be the best to try and protect the most inexperienced (or laziest :) users | 11:24 |
| davidcalle | sonne, there is a discoverability issue of that setting, that's true. Hopefully, it will evolve into something most users are happy with :) | 11:28 |
| sonne | let's hope it... the whole thing has raised way many concerns, it would be a shame to lose userbase on a wonderful product as ubuntu for such a trifle | 11:30 |
| sonne | davidcalle, reading the lens source code for ringtail, i see that the https handling is delegated to the vala libraries... i'm wondering how strict is their certificate authenticity check | 11:34 |
| davidcalle | sonne, I actually have no idea about the Vala ones. I guess you could ask that to pstolowski in #ubuntu-unity. | 11:35 |
| sonne | thanks for the pointer :) | 11:36 |
| davidcalle | sonne, np :) | 11:36 |
| zyga | utlemming: around? | 11:38 |
| zyga | pitti: last night we've updated virtualbox to 4.2, breaking vagrant 1.0.3 that does not support it, we're in feature freeze now, upstream vagrant 1.0.6 works okay, what can I do to get 1.0.6 into raring? I'm trying to package 1.0.6 based on the current package but my git-buildpackage foo is low | 11:39 |
| pitti | zyga: ah, you want to update it in collab-maint? | 11:42 |
| zyga | pitti: yes but I don't know how | 11:42 |
| zyga | pitti: I got the upstream git tree, I've exported 1.0.6 from the tag | 11:42 |
| zyga | pitti: I've got the debian collab-maint tree as well | 11:43 |
| pitti | oh, debian's git-buildpackage trees are not based on upstream git | 11:43 |
| pitti | you usually just run git-import-orig to import a new tarball | 11:43 |
| zyga | yeah, but I needed both to get the pristine tarball, apparently upstream builds none | 11:43 |
| pitti | ah, sure | 11:43 |
| zyga | trying | 11:44 |
| zyga | woot | 11:44 |
| zyga | worked! | 11:44 |
| zyga | let me build and check this | 11:44 |
| zyga | so what happens if it works? | 11:44 |
| zyga | can you help me push 1.0.6 to debian git and sync that to ubuntu somehow? | 11:44 |
| Laney | https://github.com/mitchellh/vagrant/tags ? | 11:44 |
| pitti | zyga: yes, I can | 11:45 |
| pitti | zyga: NB that vagrant currently has some ubuntu modifications | 11:45 |
| zyga | yes | 11:45 |
| pitti | zyga: if they are applicable to Debian they should be committed there; or are they obsolete? | 11:45 |
| zyga | I saw two patches | 11:45 |
| zyga | one seems to change the location of common files, it just places /usr/share/vagrant there, seems okay | 11:46 |
| zyga | the other patch was for dns config that was affecting us ever since we've started to use the internal dns but I cannot see that patch in debian/patches anymore | 11:46 |
| zyga | but that was integrated upstream earlier | 11:47 |
| zyga | so perhaps it's no longer in the debian git tree | 11:47 |
| zyga | creating pbuilder base image | 11:49 |
| * zyga needs to grok all the packaging stuff better | 11:49 | |
| rmannibucau | Hi guys, how do i ask for the creation of a package + addition in repo for ubuntu? | 12:05 |
| zyga | rmannibucau: perhaps yuo are interested in #ubuntu-app-devel and developer.ubuntu.com? | 12:07 |
| rmannibucau | zyga, i'll conect, thanks | 12:08 |
| zyga | pitti: I cannot build a base image for git pbuilder, it stops on cowdancer being missing: http://pastebin.ubuntu.com/5595765/ should I be doing this? | 12:09 |
| pitti | zyga: hm, I'm afraid I never did that; for raring I just build on my normal system, and use schroot for everything else | 12:09 |
| pitti | zyga: perhaps there's a way to disable cowdancer and just use classic tarballs and temp dirs? | 12:09 |
| zyga | ah, I can just try building the package | 12:10 |
| zyga | so that worked | 12:15 |
| zyga | woot, cool, let me check if the package works | 12:16 |
| === MacSlow is now known as MacSlow|lunch | ||
| zyga | pitti: assuming this works, what should I do next? | 12:17 |
| pitti | I guess pristine-tar etc. doens't work well with format-patch, so I suggest you push your git someplace, or tar it up and put it on people? | 12:25 |
| pitti | zyga: ^ | 12:25 |
| Laney | ~/public_git on git.d.o is nice | 12:25 |
| zyga | Laney: I don't have access to git.debian.org most likely, yet | 12:27 |
| zyga | pitti: ok, let me try that | 12:27 |
| Laney | well you can sign up, but github/gitorious/whatever also works | 12:28 |
| === dholbach_ is now known as dholbach | ||
| zyga | my ssh key does not work with people.ubuntu.com, I'll try people.canonical.com | 12:29 |
| Laney | apparently lillypilly has git installed too, so perhaps you can actually push there! | 12:29 |
| zyga | lillypilly? | 12:30 |
| Laney | people.c.c | 12:30 |
| zyga | oh | 12:30 |
| zyga | yeah | 12:31 |
| zyga | pushed to http://people.canonical.com/~zyga/vagrant.git/ | 12:32 |
| mdeslaur | xnox: you do know I was just kidding, right? :) | 12:32 |
| mdeslaur | xnox: I'll wait a week, no rush | 12:32 |
| zyga | I gave the new vagrant a run here | 12:34 |
| zyga | with fresh cloud images from cdimage.ubuntu.com | 12:34 |
| === _salem is now known as salem_ | ||
| zyga | let's see how that goes | 12:34 |
| zyga | hmm | 12:39 |
| zyga | failed to up vms? | 12:39 |
| zyga | odd | 12:39 |
| * zyga goes for lunch | 12:50 | |
| xnox | mdeslaur: i'd rather you not wait a week though =) as your bug is high priority and mine are not. | 13:01 |
| mdeslaur | xnox: ok, way a few minutes, and I'll upload it to quantal. I'll give you my precise debdiff too if you're preparing that. | 13:03 |
| xnox | mdeslaur: yeap. Finished amd64 test, only armhf test left before uploading precise debdiff. | 13:04 |
| mdeslaur | xnox: could you please add this? http://paste.ubuntu.com/5595873/ | 13:05 |
| xnox | mdeslaur: since quantal's sru was not accepted yet, you can use same version number. Or like give me debdiff for quantal. as well. | 13:05 |
| xnox | mdeslaur: looks ok to me. | 13:06 |
| mdeslaur | xnox: here's my quantal debdiff: http://paste.ubuntu.com/5595877/ | 13:06 |
| xnox | awesome, let me work those in ;-) | 13:06 |
| mdeslaur | xnox: thanks! | 13:06 |
| mdeslaur | xnox: sorry for colliding with you :) | 13:06 |
| xnox | mdeslaur: your bug report does not follow https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template though | 13:07 |
| mdeslaur | oh! right, I didn't update it yet...wait a sec | 13:07 |
| xnox | can you apply your awesome editorial skills to bug 1066032, please? | 13:07 |
| ubottu | bug 1066032 in openssl (Ubuntu Quantal) "Deadlock when reading a public key" [High,Confirmed] https://launchpad.net/bugs/1066032 | 13:07 |
| xnox | ok. cool. | 13:08 |
| mdeslaur | xnox: done, thanks | 13:13 |
| xnox | cool =) | 13:14 |
| OdyX | tkamppeter: despite my wrong changelog entry in foo2zjs, the code is correct and cares about Ubuntu for mscompress; hence there was no need for a merge; you could have simply synced... | 13:46 |
| jdstrand | xnox: http://people.canonical.com/~jamie/consolekit/ | 13:49 |
| seb128 | pitti, ^ | 13:50 |
| seb128 | jdstrand, hey, thanks for the grepping ;-) | 13:50 |
| jdstrand | np | 13:54 |
| mdeslaur | infinity: do you have an apache2 merge planned soon? | 13:57 |
| === MacSlow|lunch is now known as MacSlow | ||
| seb128 | ev: hey, sorry to ping you but I'm not sure who to ask ... who is maintaining ubuntu-geonames? Is that #is? do they look at launchpad bugs? | 14:06 |
| xnox | seb128: I am the TIL on ubuntu-geonames. | 14:06 |
| xnox | seb128: what's up? | 14:06 |
| seb128 | xnox, pgraner reported https://bugs.launchpad.net/ubuntu-geonames/+bug/1150109 | 14:07 |
| ubottu | Launchpad bug 1150109 in Ubuntu Geonames "Ubuntu's geonames only knows about Hong Kong in Guyana, not in China" [Undecided,New] | 14:07 |
| xnox | seb128: we take straight database from http://www.geonames.org/ | 14:07 |
| seb128 | xnox, not sure how much of an issue that is (well, he reported that against the indicator but it turns out it's a db issue) | 14:07 |
| seb128 | xnox, but geonames.org lists Hong Kong China | 14:07 |
| seb128 | it's even the first entry | 14:08 |
| seb128 | xnox, http://geoname-lookup.ubuntu.com/?query=hong%20kong doesn't | 14:08 |
| xnox | seb128: they have full db, we have only free/small db. | 14:08 |
| xnox | seb128: but it is weird in deed. | 14:08 |
| seb128 | xnox, well, Hong Kong is not really small ;-) | 14:08 |
| seb128 | we should have it in our db | 14:08 |
| xnox | seb128: yeah, I'll debug it here locally, assign that bug to me plese. | 14:09 |
| seb128 | xnox, thanks | 14:09 |
| seb128 | (done) | 14:10 |
| smoser | cjwatson, around ? i'm wondering if you've done before, or would have thoughts on how i could prototype eatmydata use of d-i | 14:19 |
| Daviey | smoser: Don't you just need to LD_PRELOAD it? | 14:23 |
| cjwatson | My suggestion to psusi was to put it in in-target, in debian-installer-utils | 14:23 |
| cjwatson | For prototyping, just edit stuff on the fly in the running installer | 14:23 |
| cjwatson | Grr, where oh where did I put my secondary backup disk | 14:25 |
| smoser | Daviey, yes, you just LD_PRELOAD it, but i didn't know if there was a clear path to injecting that into the installer then that would immediately affect the majority of the install process. | 14:25 |
| xnox | ev: Daviey: my lcy02 troubles ended up being a combination of old sshebang, old novarc, old default-image-id and a wrong ssh key =) | 14:25 |
| cjwatson | in-target won't affect debootstrap but will handle the bulk of everything else. | 14:26 |
| * xnox really had no chances =)))) | 14:26 | |
| xnox | works fine now. | 14:26 |
| smoser | maybe i'll just patch the initramfs launch of the installer. | 14:26 |
| cjwatson | Please don't. Use in-target | 14:26 |
| xnox | smoser: I've had stuff spuriously failing with eatmydata, due to things not being present when there were expected to be already. | 14:27 |
| cjwatson | Indeed, I do not want this to e.g. interfere with partitioning in some way | 14:27 |
| cjwatson | It should be constrained to operations on the target system | 14:27 |
| smoser | hm.. | 14:27 |
| xnox | smoser: it's best to start with in-target and then slowly move up until required performance / speed is gained. E.g. in-target will be the majority gain. | 14:28 |
| xnox | anyway. | 14:28 |
| cjwatson | You'll have to do it in a couple of places but that's no big deal | 14:28 |
| zyga | hey, perhaps someone can hint me with a package I'm trying to make, it's actually a straightforward package but it's nested in a directory, without that I could do all on dh, is there a way to somehow "cheat" that? | 14:33 |
| xnox | zyga: man debhelper, see common buildsystem options to specify "src" directory. | 14:44 |
| zyga | xnox: thanks! | 14:45 |
| xnox | zyga: so you'd need to override_dh_auto_[build|configure|install|test]: with dh_auto_build --sourcedirectory=subdir1/component/plugin/ | 14:46 |
| tumbleweed | no, you can pass options to dh | 14:46 |
| xnox | zyga: I had a hack somewhere to auto strip override_ prefix, to have all four targets. | 14:46 |
| xnox | zyga: dh --sourcedirectory=foobar shoudl work, but it didn't in the past. | 14:46 |
| zyga | hmm | 14:47 |
| zyga | I was just looking at that and wondering if there's DH_OPTIONS that could get that somehow, let me keep trying | 14:47 |
| tumbleweed | I think that happens through DH_OPTIONS magic | 14:47 |
| tumbleweed | ah, DH_INTERNAL_OPTIONS | 14:48 |
| psusi | I'm planning on patching in-target as cjwatson suggested | 14:50 |
| xnox | smoser: ^ | 14:50 |
| psusi | just need to build a custom preseeded install cd to benchmark before slipping in the patched debootstrap, then the patched d-i/in-target and measuring the difference | 14:50 |
| smoser | psusi, you know that you can easily patch an initramfs by just appending a gzipped cpio to it, right? | 14:56 |
| smoser | i'm sure you're aware, but thats probably the fastest way to hijack (and you can insert a preseed that way too) | 14:56 |
| cjwatson | For experimentation it's way easier to just edit on the fly | 14:56 |
| psusi | have to patch the cd to include eatmydata anyhow | 14:57 |
| cjwatson | Also not that hard to build modified udebs, slap them in build/localudebs/ in the debian-installer source, and build a modified initramfs from there | 14:57 |
| smoser | psusi, you can just shove it insto the initramfs, no? | 14:57 |
| cjwatson | smoser: no, needs deb | 14:57 |
| cjwatson | well, maybe | 14:57 |
| cjwatson | I guess a udeb wouldn't be a terrible idea | 14:58 |
| psusi | smoser: no, it needs installed into the target system ;) | 14:58 |
| psusi | udeb shouldn't be needed since it isn't intented for the installer to use right? just the target | 14:58 |
| cjwatson | depends on whether it's easier to invoke it in the chroot or not | 14:59 |
| psusi | so I've patched debootstrap to force install it during the stage 1 bootstrap, then set the LD_PRELOAD to use it during the second phase... so just need to have in-target also set the LD_PRELOAD so it continues to be used during the rest of the in-target install process | 14:59 |
| cjwatson | BTW building CDs for this is a mug's game - use netboot for testing, it's way faster | 14:59 |
| cjwatson | with a local mirror anyway | 14:59 |
| psusi | hrm... have to set up a local mirror then... | 14:59 |
| smoser | psusi, squid proxy is simpler there i think. | 15:00 |
| psusi | figured it would be easier to just download and modify the cd than to download and setup a local mirror... | 15:00 |
| smoser | anyway, psusi i'm interested in your progress there. | 15:01 |
| smoser | http://smoser.brickies.net/git/?p=tildabin.git;a=blob;f=overlay-initramfs;hb=HEAD | 15:01 |
| smoser | thats my "overlay-initramfs" if you're interested. it just makes patching an initramfs (possibly) simpler. | 15:02 |
| tkamppeter | slangasek, system-config-printer 1.3.12+20130308-0ubuntu1 uploaded. | 15:05 |
| OdyX | tkamppeter: I'm uploading latest foo2zjs to experimental, you can sync without merge as far as I can see; just ask if there's something left to accomodate. | 15:10 |
| tkamppeter | OdyX, only Ubuntu-specific which I have in foo2zjs is that printer-driver-foo2zjs depends on mscompress. | 15:16 |
| OdyX | tkamppeter: I have handled that difference specifically in my uploads to Debian experimental. | 15:18 |
| === kentb-out is now known as kentb | ||
| OdyX | tkamppeter: granted, my changelog entry was backwards (now corrected), but I made my possible to reduce your work. :) | 15:19 |
| tkamppeter | OdyX, great, thank you. | 15:41 |
| OdyX | tkamppeter: my pleasure. | 15:41 |
| slangasek | roaksoax: if adding a Conflicts: maas-provision to maas, in addition to the Conflicts: on tftpd-hpa, didn't do it, the only other thing I can think of would be to convert maas-provision into a dummy package for upgrade. | 15:42 |
| roaksoax | slangasek: i think that would be the only option | 15:43 |
| dsathe | hello all , i am not sure if this is the right place to ask but i couldn't find a better place | 15:51 |
| dsathe | hello , could someone help me understand cgroup cpuacct | 15:51 |
| dsathe | i had a few specific queries | 15:51 |
| dsathe | the cpuacct.usage displays the number of nano seconds used by the cgroup | 15:52 |
| dsathe | and the stat shows nett and user usages | 15:52 |
| dsathe | how are these 2 related , and say i wanted to compute the net cpu utilization of a cgroup how would i do that ? | 15:53 |
| roaksoax | slangasek: so basically, make maas-provision binary not depend on anything and not install anything either? | 15:57 |
| tkamppeter | slangasek, hi | 15:59 |
| OdyX | tkamppeter: can you prepare a cups-filter 1.0.30-1 upload to Debian experimental ? | 16:00 |
| tkamppeter | OdyX, I will do it, I am currently only putting in the last packages for Ubuntu FF. | 16:02 |
| tkamppeter | slangasek, can you sync QPDF 4.0.1 from Debian experimental to Raring for me? It fixes bug 923955, printing filled PDF forms. | 16:03 |
| ubottu | bug 923955 in qpdf (Ubuntu) "pdftopdf filter fails to output form field values" [Undecided,Confirmed] https://launchpad.net/bugs/923955 | 16:03 |
| tkamppeter | slangasek, can you also sync foo2zjs_20130306dfsg0-1 from debian/experimental? OdyX has uploaded it now and it contains important bug fixes. | 16:05 |
| pitti | jdstrand, seb128: archive grep> thanks! | 16:08 |
| slangasek | tkamppeter: if you don't have access to sync these yourself, it's probably best if you use the normal sponsorship process (or ping someone who usually sponsors these things for you) - I'm not free just at the moment :) | 16:10 |
| slangasek | tkamppeter: btw, on system-config-printer you sent an email asking if it was ok to update it, then you uploaded it - you understand that there is no frozen queue in the archive right now, so that upload has gone in directly? (i.e., there's no way for me to say 'no' now anyway) | 16:11 |
| tkamppeter | slangasek, thanks. | 16:15 |
| jdstrand | pitti: sure thing :) | 16:15 |
| tkamppeter | pitti, can you sync qpdf from experimental for me? | 16:15 |
| === Ursinha-afk is now known as Ursinha | ||
| tkamppeter | slangasek, foo2zjs I will sync by myself then, it only needs to arrive in the Debian archives. | 16:16 |
| pitti | tkamppeter: done | 16:16 |
| xnox | tkamppeter: fire off `syncrequest -d experimental qpdf` to file a bug, then it will get into the sponsorship queue =) http://reqorts.qa.ubuntu.com/reports/sponsoring/ | 16:16 |
| pitti | too late :) | 16:16 |
| xnox | tkamppeter: snap. pitti is quick =) | 16:16 |
| tkamppeter | OdyX, how long does it take until your foo2zjs from today gets syncable for Ubuntu. | 16:17 |
| tkamppeter | xnox, thanks anyway. | 16:17 |
| tkamppeter | pitti, thanks for syncing. | 16:17 |
| Laney | tkamppeter should apply for upload rights to printing stuff | 16:17 |
| OdyX | tkamppeter: I got the "UPLOADED" mail minutes ago, I suspect something in the range of hours, at most. | 16:17 |
| tkamppeter | Laney, I am already per-package uploader for printing stuff, only QPDF seems to be missing (neds to get added by the TB). | 16:18 |
| OdyX | tkamppeter: I'm not clear with what status the Debian packages must be in for a sync to succeed, so I don't really know. | 16:18 |
| tkamppeter | OdyX, the Ubuntu syncpackage still found only 20130303dfsg0-1 and not 20130306dfsg0-1 | 16:19 |
| xnox | tkamppeter: check http://pad.lv/d/$packagename that's Debian mirror in launchpad. Once launchpad's mirror has the package, one can sync it. | 16:19 |
| xnox | (look for latest upload, if stuff is in experimental) | 16:19 |
| OdyX | tkamppeter: it's currently being built on the buildds so I guess it's "soon" now ;) | 16:20 |
| tkamppeter | xnox, thanks. | 16:20 |
| OdyX | tkamppeter: it might be useful for Ubuntu to sync foomatic-db 20130301 too | 16:23 |
| tkamppeter | OdyX, I have already updated to 20130308. | 16:23 |
| OdyX | tkamppeter: while there was no new change since then ? I'm surprised, as I thought it'd take less time to sync than to upload; apparently I'm wrong. ;) | 16:25 |
| infinity | mdeslaur: I can do one. | 16:26 |
| mdeslaur | infinity: ok, thanks | 16:26 |
| roaksoax | slangasek: yeah the dummy package seems to do the trick! Thanks :) I would have never thought about that :) | 16:27 |
| roaksoax | slangasek: but i think the other option would simply be to remove tftpd-hpa as a recommends of maas-provision | 16:31 |
| roaksoax | that would introduce less change | 16:31 |
| DooMMasteR | hi there… | 16:45 |
| DooMMasteR | I have a "little" problem | 16:45 |
| DooMMasteR | running ubuntu on a PC with a radeon HD4850 and the OSS radeon driver (not catalyst) result in a 80% certain reboot for me when using one of the fancy unity features | 16:46 |
| DooMMasteR | Alt+Tab, Windowskey or so on | 16:46 |
| DooMMasteR | once it works… it runs solid | 16:46 |
| DooMMasteR | and no logentries whatsoever | 16:49 |
| xnox | stokachu: bug 578536 is being removed from lucid-proposed. because it has not been verified in a timely fashion. | 17:07 |
| ubottu | bug 578536 in autofs5 (Ubuntu Lucid) "when stopped, automount orphans some mounts" [Medium,Confirmed] https://launchpad.net/bugs/578536 | 17:07 |
| xnox | stokachu: i'd think we care about it ^ | 17:07 |
| stokachu | xnox: yep already spoke to bdmurray about it | 17:07 |
| xnox | stokachu: is that ok or not? | 17:07 |
| stokachu | yea | 17:07 |
| stokachu | i personally care but the ones affected by it have since migrated to precise | 17:08 |
| xnox | stokachu: oh, nice fair enough =) | 17:08 |
| stokachu | thanks for the heads up :P | 17:08 |
| xnox | stokachu: I wish you'd idle on #ubuntu-release =) this is were I noticed it. | 17:09 |
| tkamppeter | OdyX, foo2zjs 20130306 did not yet arrive on https://launchpad.net/debian/+source/foo2zjs, are you sure it built properly on the Debian buildds? | 17:10 |
| OdyX | tkamppeter: https://buildd.debian.org/status/package.php?p=foo2zjs&suite=experimental says that it was indeed, unless you need mipsel (don't know why i386 isn't built yet) | 17:11 |
| slangasek | roaksoax: as long as that's a reasonable change, and has the intended effect, sure | 17:15 |
| bdmurray | seb128: I'm not sure if you saw my lightning talk but https://errors.ubuntu.com/?user=desktop-packages | 17:17 |
| seb128 | bdmurray, no, I didn't, that's nice! | 17:18 |
| ogra_ | he was to distracted by the comics :) | 17:18 |
| seb128 | lol | 17:18 |
| bdmurray | seb128: so those are all the packages that that launchpad team is subscribed to | 17:18 |
| seb128 | ogra_, I was rather giving a chance to my laptop to cool down in the middle of a day of running hangouts :p | 17:18 |
| ogra_ | heh | 17:18 |
| * ogra_ never runs hangouts on his laptops ... | 17:19 | |
| ogra_ | but thats just googles fault ... not providing it for arm :) | 17:19 |
| === rickspencer3_ is now known as rickspencer3 | ||
| zyga | ogra_: with what's going on you may not need a plugin soon | 17:29 |
| ogra_ | hopefully | 17:29 |
| * zyga wonders how to use two buildystems listed by dh --list at the same time | 17:30 | |
| zyga | I want python3 and sphinxdocs | 17:30 |
| mitya57 | these are not buildsystems, but plugins — you can use "dh --with python3,sphinxdoc" | 17:33 |
| zyga | ah | 17:35 |
| zyga | thanks | 17:35 |
| zyga | the man page was confusing | 17:35 |
| zyga | hmm, it seems that dh --sourcedirectory is ignored by dh_sphinxdoc | 17:41 |
| zyga | or I'm doing it wrong, passing --sourcedirectory to dh | 17:41 |
| geofft | Is that an option to dh_sphinxdoc or to dh? | 17:41 |
| mitya57 | to dh | 17:42 |
| mitya57 | how is dh_sphinxdoc ignoring it? | 17:42 |
| zyga | geofft: to dh | 17:42 |
| tumbleweed | does the source directory matter to dh_sphinxdoc? | 17:42 |
| zyga | mitya57: it's not finiding any docs, this is a perfectly standard python3 + setup.py + sphinx package | 17:42 |
| tumbleweed | dh_sphinxdoc cleans up things that have been dh_installed | 17:43 |
| zyga | _or_ I may misunderstand what I need to do | 17:43 |
| zyga | like build docs explicitly | 17:43 |
| zyga | but that's not specified so I don't know | 17:43 |
| mitya57 | dh_sphinxdoc doesn't build docs | 17:43 |
| zyga | oh | 17:43 |
| zyga | that's confusing then, ok, let me see if I can build docs explicitly | 17:44 |
| tumbleweed | zyga: there's nothing in dh_sphinxdoc's manpage that makes me believe it would build docs | 17:45 |
| zyga | tumbleweed: apart from the obvious name that suggest otherwise | 17:45 |
| tumbleweed | no dh_programs build anything | 17:46 |
| tumbleweed | dh_auto_programs do building etc | 17:46 |
| zyga | ah | 17:46 |
| zyga | I wasn't aware of that | 17:46 |
| zyga | but if there's only dh_auto_build does that mean ther dh-* programs can plug into that to tell it how to build something? | 17:47 |
| mitya57 | dh_auto_build calls the relevant buildsystem | 17:48 |
| tumbleweed | dh_auto_* use buildsystems /usr/share/perl5/Debian/Debhelper/Buildsystem/ | 17:48 |
| tumbleweed | dh_* do little jobs related to preparing a package, totally independant of build systems. | 17:48 |
| zyga | so all the logic is in python3 buildsystem then, right? | 17:48 |
| tumbleweed | there isn't a python3 buildsystem | 17:49 |
| mitya57 | there are distutils and pybuild :) | 17:49 |
| tumbleweed | you are thinking of dh_python3, which just handles .pyc generation, dependencies etc. | 17:49 |
| zyga | I'm trying to figure out if sphinx docs should build automatically and where to find the code that pokes setup.py | 17:49 |
| mitya57 | s/distutils/python_distutils/g | 17:50 |
| tumbleweed | zyga: nothing builds sphinx automatically, you do it by hand - it takes one command... | 17:50 |
| zyga | and I guess I should be using pybuild? | 17:50 |
| mitya57 | the code is in the relevant buildsystem, in the directory tumbleweed mentioned | 17:50 |
| zyga | tumbleweed: ah, with all the automation I was expecting that to be called too, thanks | 17:50 |
| tumbleweed | pybuild is still brand new, but, yeah | 17:50 |
| * zyga looks at that now | 17:50 | |
| * tumbleweed hasn't used it for anything yet | 17:51 | |
| mitya57 | brand new = available only in raring/experimental | 17:51 |
| zyga | so no way for it to target precise for example? | 17:51 |
| tumbleweed | zyga: while we are talking about this, --with adds things to dh's sequences - see /usr/share/perl5/Debian/Debhelper/Sequence/ | 17:51 |
| tumbleweed | zyga: correct, if you care about precise, do it by hand | 17:51 |
| zyga | ok, let me try to get the basics first | 17:51 |
| zyga | thanks btw! | 17:51 |
| * zyga would wish for the buildsystem glue parts to be backported/SRUd to LTS to allow developers to target that while benefiting from the advancements | 17:52 | |
| mitya57 | but if your package is python3-only then python_distutils won't help you | 17:53 |
| zyga | it is | 17:53 |
| zyga | so I can only use pybuild? | 17:53 |
| tumbleweed | or by hand | 17:53 |
| zyga | oh | 17:53 |
| tumbleweed | like we all do | 17:53 |
| micahg | any reason why we can't backport pybuild to precise? | 17:53 |
| zyga | so by hand I'd have to define overide_dh_auto_{build,clean,install} | 17:54 |
| * tumbleweed hasn't investigated | 17:54 | |
| * mitya57 thinks we can | 17:54 | |
| zyga | and basically run the relevant command there | 17:54 |
| zyga | ok | 17:54 |
| zyga | let me try stuff first | 17:54 |
| tumbleweed | zyga: yes. http://wiki.debian.org/Python/LibraryStyleGuide | 17:54 |
| micahg | oh, hrm, is it part of the python sourcE? | 17:54 |
| tumbleweed | micahg: that's the complication... | 17:55 |
| mitya57 | micahg: it's part of python3-defaults source | 17:55 |
| tumbleweed | but unlike dh_python2, it doesn't depend on pythonX.Y patches | 17:55 |
| mitya57 | but there was a plan to move that out | 17:55 |
| micahg | if it was its own source,it would be easy to backport | 17:55 |
| zyga | tumbleweed: that's very very helpful, thanks | 17:56 |
| tumbleweed | micahg: chat to piotr | 17:56 |
| tumbleweed | zyga: barry wrote that - it's not the style I use, but it should be helpful, yes | 17:56 |
| xnox | zyga: but we don't have nearly as many python packages available with python3 support in precise as we do in quantal. we did massive push for python3- packages at the start of quantal. | 17:56 |
| micahg | tumbleweed: someone else chat and I'll volunteer to twiddle the bits to make the backport happen once it's tested :) | 17:56 |
| zyga | I'm starting the package from scratch based on the docs tumbleweed linked to | 18:05 |
| zyga | do you know of the top of your head if using --sourcedir will allow me to keep using . as the source directory or do I need to mirror everything in each rule | 18:05 |
| tumbleweed | . is the default source directory | 18:07 |
| zyga | right but I cannot use that, sadly | 18:08 |
| dobey | zyga: you need to package something that's using both python2 and 3 on precise? | 18:08 |
| tumbleweed | oh, ISWYM. options passed to dh will still apply thansk to the magic of environment variables | 18:08 |
| zyga | dobey: no, only python3, but I wanted to use the fancier/better build system | 18:09 |
| zyga | (this is a pure python3 package) | 18:09 |
| dobey | ah | 18:10 |
| zyga | we have an unusual layout where three projects share a repository as they are coupled but need to release on separate schedule, I'm building the daily-ppa recipe+packaging | 18:12 |
| dobey | zyga: all the u1 stuff is python2 (or 2 and 3), but this one might be helpful for you: https://bazaar.launchpad.net/~ubuntuone-control-tower/dirspec/packaging-dailies/files | 18:13 |
| zyga | thanks, looking | 18:13 |
| dobey | zyga: you don't also need to build on lucid do you? just precise and newer? | 18:13 |
| zyga | what are dirspec files? | 18:14 |
| zyga | just precise-quantal-raring | 18:14 |
| zyga | actually | 18:14 |
| dobey | dirspec is a python module that implements the XDG base directory specification | 18:14 |
| zyga | oh | 18:14 |
| zyga | why is that in the package? I'm probably missing something | 18:15 |
| dobey | that's the branch with the dailies packaging info | 18:15 |
| zyga | ohhhh | 18:15 |
| zyga | sorry | 18:15 |
| * zyga was dumb | 18:15 | |
| dobey | :) | 18:15 |
| zyga | :) | 18:15 |
| zyga | I thought somehow debian packaging had something to do with XDG dirs, it's just the package name here | 18:16 |
| dobey | i think you can use that and just remove the python2-specific bits (and change the auto_test override and such if needed) to build for python3 only | 18:16 |
| === shadeslayer_ is now known as shadeslayer | ||
| dobey | zyga: yeah, sorry. that's just the project/package name. we have all the daily build branches as lp:$project/packaging-dailies for ubuntuone stuff :) | 18:17 |
| * zyga has to somehow drop the linaro cloak | 18:18 | |
| zyga | hmm, it's not right | 18:26 |
| zyga | http://pastebin.ubuntu.com/5596705/ line 148 makes me think that I need to somehow quote -D (aka --sourcedir) when I pass it to dh, it gets glued on top of other options the line after that | 18:27 |
| zyga | tumbleweed: sorry to bother you with that but apparently --sourcedirectory= does nothing in practice, all of other make target still run start running in the top-level package directory. Do you know if that's correct / expected or is it just some other mistake on my sinde? | 18:38 |
| zyga | side | 18:38 |
| tumbleweed | zyga: sourcedir should only affect dh_auto_... | 18:39 |
| zyga | so in pratice I need to pass it to dh _and_ actually use it on all the commands I add on top | 18:40 |
| xnox | zyga: if you override dh_auto_configure, then yes you will have to add --sourcedir there. | 18:40 |
| zyga | grepping for that I find very little references, all in Dh_Buildsystem.pm (opt_sourcedir) | 18:40 |
| xnox | zyga: note that dh_install has no idea about sourcedir, only dh_auto_configure|build|install|test do. | 18:40 |
| tumbleweed | xnox: practically, I don't think so, thanks to environment variable magic | 18:40 |
| zyga | let me try something\ | 18:41 |
| xnox | tumbleweed: hmm.. interesting. I should experiment more with it then. | 18:41 |
| tumbleweed | zyga: if yu are doing a pure-python3 package you have to override dh_auto_* anyway, so --sourcedir is moot | 18:42 |
| xnox | zyga: what are you packaging? do you have a tiny example. It's easier to prototype / tinker with stuff. | 18:42 |
| zyga | xnox: sure, I'm packaging plainbox, it's a rewrite of checkbox, the code is in lp:checkbox (in the plainbox directory there), the package is still on my disk but it's vanilla example as copied from http://wiki.debian.org/Python/LibraryStyleGuide | 18:43 |
| xnox | zyga: and you will still be building the rest of checkbox at the same time? or separate source package? | 18:45 |
| zyga | a simple echo + pwd shows that --sourcedirectory does not do any magic to redirect where all the commands from debian/rules are started in | 18:45 |
| zyga | xnox: no, checkbox is separate and will stay that way | 18:45 |
| zyga | xnox: plainbox is a fresh start so to speak | 18:45 |
| zyga | xnox: checkbox is actually a native package so it's even worse than that | 18:46 |
| xnox | zyga: sure, so why doen't it release fresh tarballs as top level =) or are you shipping duplicate source code in two packages? | 18:46 |
| zyga | xnox: plainbox is normally published on pypi, only the part that builds the daily deb has to worry about the layout | 18:46 |
| xnox | zyga: ah, for daily build we can do ugly hacks and tricks then! | 18:47 |
| xnox | awesome, gotcha. | 18:47 |
| zyga | yeah | 18:47 |
| zyga | the normal package should be far saner | 18:47 |
| zyga | :-) | 18:47 |
| zyga | ok, let me add ( cd plainbox && ..) to all the places that matter then | 18:48 |
| xnox | zyga: I would do "normal" packaging in plainbox/debian (such that it can be later reused for archive uploads) and in the top level ./debian/rules change it to be a wrapper script, and symlink the copyright & control. | 18:48 |
| zyga | hmm | 18:48 |
| zyga | let me think about that because I'm not sure I understand | 18:49 |
| xnox | the wrapper script simply does ( cd plainbox && ./debian/rules $@) | 18:49 |
| zyga | ah | 18:49 |
| zyga | right | 18:49 |
| zyga | nice | 18:49 |
| zyga | yeah, that might work | 18:49 |
| zyga | I need to see if it will work with the way the recipe is expressed | 18:49 |
| zyga | it uses nest-part and stuff like that | 18:49 |
| xnox | but you will need to symlink control & changelog, as those two things are looked up by e.g. debuild and etc. | 18:50 |
| zyga | and starts with the _packaging_ branch, not lp:checkbox, because it's impossible to nest-part of the root recipe repository | 18:50 |
| zyga | right, I get that | 18:50 |
| zyga | xnox: neat idea, let's see | 18:50 |
| xnox | zyga: if you use a recipe, you can nest the _other_ way around. and it should work. | 18:50 |
| zyga | xnox: other? | 18:50 |
| xnox | starting recipe from packaging branch is good in this case. | 18:50 |
| xnox | (that's what I meant) | 18:51 |
| zyga | http://pastebin.ubuntu.com/5596780/ | 18:51 |
| zyga | right | 18:51 |
| zyga | that's what I do | 18:51 |
| xnox | hmm... | 18:51 |
| xnox | wait my hacks might not work then. Or can you commit /plainbox/debian to lp:checkbox? | 18:52 |
| zyga | xnox: we _could_ but I think we don't want to | 18:53 |
| xnox | zyga: fair enough. | 18:53 |
| zyga | xnox: we had debian in checkbox forever and that's a pain to keep | 18:53 |
| zyga | xnox: all the changelog updates conflict on merges | 18:53 |
| xnox | =) | 18:53 |
| xnox | _very good_ | 18:54 |
| zyga | xnox: with plainbox I always wanted to do packaging with git and build debian/changelog from the git log | 18:54 |
| zyga | (but that's hard to do since I was asked to use bzr) | 18:54 |
| zyga | almost done with that wrapper layout | 18:54 |
| xnox | unless you maintain a mirror, but yeah, still a pain. | 18:54 |
| xnox | zyga: yeah, i fear it might fail to build though. | 18:54 |
| xnox | zyga: how far back do you need support? precise? | 18:55 |
| zyga | yes | 18:55 |
| zyga | I'm fine with doing a different build for precise | 18:55 |
| zyga | even from manual releases | 18:55 |
| zyga | though I _may_ be wrong still | 18:55 |
| zyga | we do some magic in which version is used | 18:56 |
| zyga | as in: for ubuntu we have stuff in lp:ubuntu/checkbox | 18:56 |
| zyga | for development, we have a ppa | 18:56 |
| zyga | for everyone else (lots of uses) we have a second ppa | 18:56 |
| xnox | zyga: so using this: http://wiki.debian.org/Python/AppStyleGuide | 18:56 |
| zyga | (so the recipe does not work as both have 'plainbox' directory, boo, let's see if I can make that work somehow | 18:56 |
| xnox | zyga: python2 only or both python2 and python3 supported with plainbox? | 18:57 |
| zyga | the full code is in python3.2+, no support for 2.* at all | 18:57 |
| xnox | good. | 18:58 |
| zyga | I think I know how to solve that | 19:00 |
| zyga | I'll do even crazier redirect | 19:00 |
| zyga | the top level will redirect to nest-ed checkbox/plainbox | 19:00 |
| zyga | so no conflicts on debian/ from lp:checkbox | 19:00 |
| zyga | xnox: that worked :D | 19:05 |
| zyga | awesome | 19:05 |
| zyga | that has to be the most tricky package I ever did | 19:06 |
| xnox | zyga: and build the source package -> that can build binary package? | 19:06 |
| zyga | thanks a _lot_ xnox, tumbleweed, dobey | 19:06 |
| zyga | yes | 19:06 |
| zyga | and run the test suite | 19:06 |
| zyga | and has autopkgtests | 19:06 |
| zyga | and docs | 19:06 |
| tumbleweed | np | 19:06 |
| xnox | zyga: for reference this works for me - http://paste.ubuntu.com/5596825/ | 19:09 |
| zyga | thanks | 19:10 |
| xnox | obviously needs additional overrides for test/clean. | 19:10 |
| zyga | oh, translations | 19:10 |
| zyga | I need to look at that | 19:10 |
| zyga | the package is not done yet, it still builds phony/broken python2 layout, I just added --without python2 | 19:10 |
| zyga | but I'm on the right track | 19:10 |
| xnox | zyga: yeah, checkbox is on the livecd so it intergrates with language packs. | 19:10 |
| zyga | and that's what --with translations does? | 19:10 |
| xnox | yes. | 19:11 |
| xnox | zyga: better echo 9 > debian/compat | 19:11 |
| xnox | zyga: that prevents running python-support, and no need to do "--without". | 19:11 |
| xnox | zyga: debhelper 9 is in precise. | 19:11 |
| zyga | ah, cool | 19:11 |
| xnox | (and it's --without python-support | 19:11 |
| xnox | ) | 19:11 |
| xnox | zyga: or wherever debian/compat is located in your case =)))))) | 19:12 |
| zyga | I guess I spoke too soon, some of the symlink magic is wrong, let me read the full log | 19:13 |
| zyga | heh, yes | 19:13 |
| zyga | at the end, dh expects debian/ to have stuff that's really in checkbox/plainbox/debian | 19:14 |
| zyga | hmm | 19:14 |
| xnox | zyga: yeah, hence my paste above as to making it work "normally" | 19:16 |
| zyga | looking again | 19:16 |
| zyga | ok, let's see | 19:17 |
| xnox | zyga: here is slighltly better version http://paste.ubuntu.com/5596840/ , doesn't run any tests, and works with just normal subdir. | 19:22 |
| zyga | let me pastebin mine, it's based on the previous one from you | 19:23 |
| zyga | actually, since I snapshot everything: lp:~zkrynicki/+junk/plainbox-daily-pkg | 19:24 |
| zyga | mine is still broken, give me a sec | 19:24 |
| xnox | I prefer make functions over embedding shell lines \ | 19:24 |
| xnox | with continuation lines | 19:24 |
| xnox | \ | 19:24 |
| zyga | yeah, I just copied the example from barry | 19:24 |
| xnox | *whoops forgot \ * | 19:24 |
| barry | whu? huh? | 19:25 |
| xnox | zyga: yeah, but it does stuff that you don't need e.g. python2 as well as python3. | 19:25 |
| xnox | barry: your wiki page on debian.org. go back to idling =) | 19:25 |
| barry | xnox: o/ | 19:25 |
| xnox | \o | 19:25 |
| xnox | barry: w.d.o/py3/LibraryStyleGuide that is in above reference | 19:26 |
| * barry nods | 19:26 | |
| zyga | ah, typo and it should really work | 19:31 |
| zyga | yes | 19:32 |
| zyga | woot | 19:32 |
| jbicha | micahg: I didn't realize gimp was still in main so it'll need a sponsor | 19:33 |
| zyga | the -docs package is empty, everything is in the main, let's see | 19:33 |
| micahg | jbicha: I can do that (though maybe not until Sunday), where's the debdiff | 19:33 |
| zyga | ah | 19:34 |
| zyga | barry: "You will not need an .install file for the documentation (TBD: explain why this works automatically)" | 19:34 |
| zyga | barry: quoting http://wiki.debian.org/Python/LibraryStyleGuide | 19:34 |
| zyga | barry: my package has no python2 support so I named the main docs package python3-plainbox-docs | 19:34 |
| zyga | barry: does that not count under the 'this works automatically'? | 19:34 |
| jbicha | micahg: bug 1132767 | 19:35 |
| ubottu | bug 1132767 in gimp (Ubuntu) "Update GIMP to version 2.8.4" [Undecided,Triaged] https://launchpad.net/bugs/1132767 | 19:35 |
| barry | zyga: sorry, my stack is too deep atm ;) | 19:35 |
| zyga | barry: ok, np :) | 19:35 |
| zyga | xnox: ^^ do you know why -docs packages don't need '.install' file? | 19:36 |
| dobey | "If upstream has documentation that's built by Sphinx, these next few lines will build and install them for the separate python-foo-docs package mentioned above." | 19:38 |
| dobey | zyga: ^^ perhaps that section is why? | 19:38 |
| zyga | dobey: thanks, I was looking at that now, the problem here is that it assumes hybrid 2k-3k packages and for packages that don't support python2 it makes no sense for python-foo-doc package | 19:40 |
| zyga | dobey: I've just added an install file for -doc to see if that's all I nee | 19:40 |
| zyga | need | 19:40 |
| dobey | zyga: well, it's easy enough to test and correct if it fails, i guess :) | 19:40 |
| zyga | yeah | 19:40 |
| zyga | hmm, should the package have -docs (as in the wiki) or -doc as most do? | 19:41 |
| zyga | is that a bug in the wiki | 19:42 |
| captainlinux | Guys, is there any way to give a Qt application direct root privileges without making a jump from one application which will ask user to authenticate and then launch the main app with root privileges? | 19:42 |
| dobey | zyga: i think -doc is preferred. both are used according to apt-cache, but for python, most all the ones with -docs say (transitional package) | 19:43 |
| zyga | shall I edit the wiki then? | 19:44 |
| xnox | captainlinux: you can use policy kit to write a policy and package it to allow limited specific privileged actions. | 19:44 |
| dobey | zyga: i don't know. i'd let barry answer that. | 19:44 |
| xnox | captainlinux: or use pkexec. | 19:44 |
| captainlinux | xnox: My application should be able to edit files in /etc/ and I was already thinking about trying PAM-Api but I'm totally new in the native Linux development so before I will go on and hit my head against the wall I better ask for any alternatives or tricks... | 19:46 |
| xnox | captainlinux: scary. one should not programmatically be editing files in /etc/ | 19:47 |
| xnox | captainlinux: note on ubuntu phone /etc/ will be read only anyway =) | 19:47 |
| micahg | jbicha: gimp looks like a merge more than a sync since we still have changes, maybe keep the changelogs so that the reasons for the changes are clear? | 19:48 |
| captainlinux | xnox: Okay, and what if I want to edit...Let's say... /etc/default/grub would it still be a bad Idea to try editing it? | 19:48 |
| zyga | captainlinux: the problem with everything in /etc is that 1) historically they use different formats 2) most are pretty much mini-programs that have control flow 3) most are designed to be read by humans | 19:55 |
| zyga | captainlinux: it's virtually impossible to have any generic too to edit all of that without starting from scratch, | 19:56 |
| zyga | captainlinux: for a particular problem, sure it might be doable | 19:56 |
| zyga | captainlinux: but getting write access is the least difficult problem | 19:56 |
| captainlinux | zyga: Okay, thanks, I understand. | 19:58 |
| xnox | captainlinux: yes. we had in the past an "editor" that was editing /etc/default/grub apart from it was inserting invalid characters, thus kernels were failing to upgrade and machines were failing to boot. | 19:58 |
| xnox | captainlinux: we have literarly thousands of bugs from users in launchpad, all of who we had to help out. | 19:59 |
| xnox | captainlinux: look for many tweak tools in the past | 19:59 |
| xnox | captainlinux: all of them eventually are broken, when config move on. | 19:59 |
| * zyga would love to see "linux" userspace to adopt plists en-masse | 19:59 | |
| xnox | captainlinux: there is no guarantee config files will stay compatible for third party applications to modify. | 20:00 |
| zyga | parsable, stronger than json, 3 encodings, including one very efficient for really large things | 20:00 |
| captainlinux | zyga: I agree on the plist thingy... | 20:01 |
| xnox | captainlinux: you could help implement https://wiki.ubuntu.com/StartupSettings | 20:02 |
| xnox | captainlinux: we have designs done, but nobody so far started to implement grub boot options as shown there. | 20:02 |
| zyga | xnox: I had to move building sphinx from override_dh_installdocs to override_dh_auto_install as otherwise the explicit -doc.install file would break the build | 20:02 |
| xnox | captainlinux: we want this as part of the ubuntu control center. | 20:02 |
| zyga | xnox: cool stuff, I didn't knew about that | 20:03 |
| captainlinux | xnox: Looks nice! | 20:03 |
| zyga | xnox: I guess it'd be possible to patch all the grub config tools to use a strict, plist/json like format and build a library that manages that, including schema changes, reverting broken configs etc | 20:04 |
| zyga | still an enormous project | 20:05 |
| zyga | and grub is quite tricky as mistake == boot gone | 20:05 |
| lifeless | booting is overrated. | 20:05 |
| * captainlinux laughs at "mistake == boot gone". | 20:05 | |
| captainlinux | But still, it's true. :) | 20:06 |
| dobey | makes it super easy to brick your phone :) | 20:07 |
| zyga | lifeless: to the meme "I don't always boot but when I do I do it right" ;) | 20:07 |
| lifeless | zyga: brilliant! | 20:08 |
| dobey | "I don't always boot, but when I do the framebuffer is full of fuzzy green stuff." | 20:09 |
| psusi | lol... the most interesting computer in the world? ;) | 20:11 |
| captainlinux | xnox: I'll definately look at this one. Seriously. | 20:11 |
| dobey | i wish i could give someone a dos equis to fix my kernel bug, at least | 20:12 |
| xnox | captainlinux: mpt did the design he hangs out here and #ubuntu-design and #ubuntu-installer. And this needs to be a plugin/page in gnome-control-center. You are more than welcome to start implementing it. And a few folks here can help with implementation (e.g. me) | 20:13 |
| * zyga would start with the low level parsing/validation/testing code | 20:14 | |
| zyga | the GUI is at the far end of that story | 20:14 |
| roadmr | hey folks, I asked a user to run apport-collect on a raring system and he says he got "this functionallity is not avaible. | 20:14 |
| zyga | or plain patches to grub config to have no need for parsing | 20:14 |
| roadmr | Launchpadlib is not installed." Is this correct? are additional packages needed for him to use apport-collect? | 20:15 |
| zyga | roadmr: the functionality of answering questions is not available ;-) | 20:15 |
| roadmr | zyga: apt-get install python-force-zyga-to-answer :D | 20:15 |
| zyga | roadmr: python3-launchpadlib maybe? | 20:15 |
| zyga | roadmr: you forgot sudo | 20:15 |
| zyga | roadmr: is launchpadlib not python2 only? | 20:15 |
| zyga | roadmr: maybe it's a bug where apport is python3 and launchpadlib isnt? | 20:15 |
| roadmr | zyga: yes I know, my question is, is an additional package required to use apport-collect? if so it seems like a sucky user experience :/ | 20:16 |
| captainlinux | xnox: Are there any restrictions to the language which should be used to implement that thingy? | 20:16 |
| roadmr | zyga: oh good point, let me check on my recently-installed raring test box | 20:16 |
| zyga | captainlinux: if you include python3, go and Qt in the list then you are good to go probably | 20:17 |
| roadmr | zyga: btw: http://xkcd.com/149/ | 20:17 |
| zyga | captainlinux: I would not touch C++ for that, python3 is probably safest for ensuring quality vs effort needed | 20:17 |
| dobey | zyga: i don't think you can write gnome-control-center plug-ins in those | 20:17 |
| TheLordOfTime | roadmr, apport-collect *shouldn't* need a separate package, last I checked, at least. | 20:17 |
| zyga | roadmr: I knew that, I was expecting it to happen :D | 20:17 |
| zyga | dobey: the backend is important | 20:17 |
| zyga | dobey: the plugin can talk to that over dbus maybe? | 20:17 |
| zyga | dobey: and be written in vala for all we care | 20:18 |
| zyga | if that backend was there and robust I would write the gui :D | 20:18 |
| roadmr | TheLordOfTime: hmm thanks... well the user reported a problem with checkbox which I can't reproduce, so I guess his system has something weird, which *may* include apport-collect being broken :/ | 20:18 |
| xnox | captainlinux: at the moment gnome-control-center is Gtk+3, if you implement this in QML / Qt+5 we should be able to integrate it as well at one point in the future. | 20:18 |
| zyga | roadmr: I remember some apport bugs when python3 transition happened | 20:18 |
| zyga | roadmr: specifically with some stuff that was 2.0 only | 20:19 |
| zyga | 2.x | 20:19 |
| roadmr | oh interesting, I got "you need to run sudo apt-get install python-apport". That's very disconcerting :/ | 20:19 |
| zyga | roadmr: but it's lated and I'm checking why dh is not installing docs at all :) | 20:19 |
| dobey | xnox: how much of the gnome bits are going to remain on the phone/tablet/converged ubuntu though? | 20:19 |
| zyga | ha | 20:19 |
| zyga | see | 20:19 |
| roadmr | zyga: hehe never mind this, I can always ask the user to just attach a log file. | 20:19 |
| zyga | roadmr: "dear user, send me your hard drive" | 20:19 |
| roadmr | better yet, the whole laptop! I can reinstall it and leave it like new %) | 20:20 |
| captainlinux | xnox: Yeah, I started to work with Qt two days ago. Immediately liked it, lol. Used to work with C# and Java on Windows and dropped C# after switching to Linux. | 20:20 |
| dobey | roadmr: please file a bug against apport about apport-collect not working | 20:20 |
| roadmr | dobey: phew, at least ubuntu-bug *does* work :D | 20:20 |
| zyga | dobey: I suspect that bug is reported if I'm correct, roadmr make sure to look for dupes first | 20:20 |
| dobey | roadmr: the "you need to install python-apport" thing is a bug | 20:21 |
| dobey | i just looked at the code to verify | 20:21 |
| zyga | oh | 20:21 |
| dobey | and it's definitely doing the wrong thing | 20:21 |
| TheLordOfTime | ah, that bug... i heard about that one... | 20:21 |
| zyga | but you know | 20:21 |
| TheLordOfTime | forgot about it for a moment there :P | 20:21 |
| zyga | if launchpadlib is 2.x only | 20:21 |
| roadmr | dobey: ok, thanks for checking! filing now... | 20:22 |
| zyga | this might be hard to solve | 20:22 |
| dobey | zy it's not | 20:22 |
| zyga | no? | 20:22 |
| zyga | ah | 20:22 |
| zyga | sorry, I was recently coding something against bzrlib | 20:22 |
| zyga | (I was using both obviously) | 20:22 |
| dobey | zyga: or well, i don't think apport uses launchpadlib any more. i think python-launchpadlib is python2 only | 20:22 |
| dobey | zyga: something saying to install launchpadlib is probably wrong | 20:23 |
| hallyn | (fwiw, apologies, i won't be able to patch-pilot today. will cathcup sometime next week) | 20:23 |
| zyga | dobey: ah, so launchpadlib _is_ 2.x only? | 20:24 |
| dobey | zyga: according to apt-cache search at least, yes | 20:24 |
| zyga | right, then I remembered correctly | 20:25 |
| zyga | it's one of the few things that prevented me from using python3 then | 20:25 |
| captainlinux | xnox: And after I saw the latest news about rewritten Unity and better Qt integration I was like, okay probably it's good to stick with Qt... | 20:26 |
| * zyga wonders how soon desktop will start replacing gnome stack with some new qt stuff | 20:27 | |
| dobey | zyga: kenvandine already rewrote gwibber in qml | 20:28 |
| zyga | dobey: I heard, and there's Friends announced recently | 20:28 |
| roadmr | dobey: filed bug 1152750, though launchpad found another that might be the same problem; I linked that in my bug | 20:28 |
| ubottu | bug 1152750 in apport (Ubuntu) "apport-collect doesn't work, asks to install python-apport" [Undecided,New] https://launchpad.net/bugs/1152750 | 20:28 |
| captainlinux | dobey: Yeah, I was really glad to see that one finally being rewritten! | 20:28 |
| xnox | captainlinux: so at the moment gnome-control-center cannot have plugins written in qt, so it will need to be integrated as a separate app/process but that's ok. | 20:29 |
| * zyga wonders about that elementaryos stack for config | 20:30 | |
| zyga | plugs? | 20:30 |
| zyga | but that's all vala | 20:30 |
| zyga | so if we're going to stick to qt it might make sense to ignore that | 20:30 |
| captainlinux | xnox: I'll think about that. Since I will have to learn some Python for my final exam anyway I can't really deny the fact that I could also try to do it in Python. | 20:31 |
| dobey | oh, apport does still use launchpadlib | 20:31 |
| dobey | it's just completely ignorant of the fact that it's not ported to python3 | 20:31 |
| dobey | someone jumped the gun on that one | 20:31 |
| zyga | ;D | 20:31 |
| zyga | I knew I was right | 20:31 |
| zyga | heh | 20:31 |
| zyga | I remember bugs about side effects of that bug | 20:31 |
| jbicha | micahg: yes it's the tradeoff between simplifying the diff with Ubuntu or simplifying the diff with Debian | 20:31 |
| dobey | so even my fixing the u1 apport hook to work in py3 doesn't help because the launchpad craschdb_impl doesn't work in py3 | 20:32 |
| dobey | whee | 20:32 |
| zyga | dobey: how hard would it be to port launchpadlib and lazr to py3k? | 20:32 |
| zyga | dobey: I kind of would like that anyway | 20:32 |
| dobey | zyga: difficulty quotient greater than 0 :) | 20:33 |
| * zyga things someone mis-scheduled porting stuff to py3k without doing those two first | 20:33 | |
| xnox | zyga: barry gave up on porting launchpadlib and the whole mess of dependencies. | 20:33 |
| zyga | ohhhh | 20:33 |
| xnox | it was a forest of problems. | 20:33 |
| zyga | barry: is porting launchpadlib hopeless? | 20:33 |
| xnox | launchpadlib is ok, all the deps are not. | 20:33 |
| dobey | there's a reason u1 isn't on py3 yet too :) | 20:33 |
| zyga | it's ironic that people can write py3k github.py file with requests and a few classes and launchpadlib is impossible to tackle | 20:34 |
| xnox | dobey: what do you mean fixing u1 apport hook to work in py3 doesn't help? why not? | 20:34 |
| zyga | dobey: deps include lazr, keyring, oauth, wadlib | 20:34 |
| * xnox thought it worked fine when i was testing my patch locally (which got redone differntly upstream) | 20:34 | |
| jtaylor | this seems to be needing fixes for our python m-a: http://www.gnu.org/software/autoconf-archive/ax_python_devel.html | 20:34 |
| dobey | xnox: because the crashdb is launchpad. so it can't actually upload anything to a bug? | 20:34 |
| xnox | zyga: wadlib was problematic. | 20:35 |
| jtaylor | someone already submotted a patch? | 20:35 |
| xnox | dobey: sure it can. apport is fully python3 only and it uploads to launchpad just fine. | 20:35 |
| zyga | xnox: depends on lazr, I assume it's from canonical then | 20:35 |
| dobey | xnox: /usr/lib/python3/dist-packages/apport/crashdb_impl/launchpad.py: from launchpadlib.launchpad import Launchpad | 20:35 |
| dobey | xnox: ^^ that says otherwise :) | 20:35 |
| zyga | xnox: but python3-wadllib is in the archive :D | 20:35 |
| zyga | xnox: so it's cannot be hard | 20:35 |
| xnox | dobey: right, but apport does execute the hooks with python3. | 20:36 |
| xnox | dobey: so they must be in python3. | 20:36 |
| dobey | xnox: which is horribly unfortunate, but eh | 20:36 |
| xnox | dobey: regardless of what is used elsewhere. | 20:36 |
| xnox | dobey: sure but I submitted a patch and it should be sru'ed into quantal. | 20:36 |
| zyga | I hope nothing ends up importing bzrlib, good luck porting that to py3k in one go | 20:36 |
| xnox | dobey: (but note that my patch was redone) | 20:36 |
| dobey | like i said. someone totally jumped the gun on porting apport to py3 | 20:36 |
| dobey | xnox: yes, i re-did it :) | 20:37 |
| zyga | dobey: I recall that was done for some other reason -- porting apport | 20:37 |
| zyga | dobey: perhaps that's was a tradeoff they took | 20:37 |
| xnox | dobey: no, they didn't. it's easy to write bilingual py2/3 and there shouldn't be anything complex required in the hooks. | 20:37 |
| xnox | zyga: push to have none or as little as possible of python2 on the cd. | 20:37 |
| dobey | xnox: i think you're confusing multiple issues | 20:38 |
| xnox | maybe =) | 20:38 |
| xnox | it's late here ;-) | 20:38 |
| xnox | and it was a full week here. | 20:38 |
| dobey | and forcing python2 apps to have to depend on python3 stuff just because apport is in py3 is silly. it means it's impossible to import something from the app itself (like say, a constants module with some information), to get more information | 20:39 |
| dobey | anyway | 20:39 |
| dobey | i'm over that | 20:39 |
| xnox | i see your point. | 20:39 |
| xnox | it was not my call to do apport in python3 in quantal =) | 20:40 |
| micahg | jbicha: personally, I don't mind changelogs as it means I don't have to hunt through the package history on launchpad | 20:41 |
| barry | zyga, xnox, dobey i'd love to see a py3 launchpadlib, and right, wadllib is done. port to built-in json, and you can drop pytho-simplejson. lazr.restfulclient and its deps are the pita. :( | 20:48 |
| barry | actually, it's deps aren't bad | 20:49 |
| barry | modulo json for simplejson, and oauthlib for oauth | 20:49 |
| barry | even lazr.uri is py3 | 20:49 |
| dobey | it's too bad that the python3-twisted* doesn't work though | 20:50 |
| barry | dobey: even after our funding? is it incomplete or is what's there just not working? | 20:51 |
| barry | dobey: (i'd like to be able to informatively harass glyph when i see him next week ;) | 20:51 |
| zyga | barry: so what is the biggest problem lazr.restfulclient? | 20:52 |
| dobey | barry: i don't remember exactly what doesn't work. i tried to run ubuntuone-dev-tools tests with it once and it was a landslide of fail though | 20:53 |
| dobey | barry: i think it's mostly trivial stuff ad tedium, though | 20:53 |
| * zyga thinks that dh_installdocs is borked | 20:54 | |
| barry | dobey: so maybe just incompatibilities, but details uncertain atm? | 20:54 |
| zyga | why is it installing stuff to $PACKAGE rather than to tmp? it breaks everything as it picks the first package from debian/control | 20:54 |
| dobey | barry: yeah. and fixing one thing leads to another, and so on, and on and on and on :) | 20:54 |
| barry | zyga: it's been quite a while since i took at crack at l.rc for py3. what work i did do is checkpointed in lp:~barry/lazr.restfulclient/py3 | 20:55 |
| dobey | zyga: do you only have one package in debian/control? | 20:55 |
| barry | dobey: sounds familiar ;) | 20:55 |
| zyga | dobey: no, three | 20:55 |
| barry | (as a side project i've been trying to port restish, and have hit a point where if a core data structure, which is a str in py2, cannot be either a str or bytes in py3 without failures somewhere) | 20:56 |
| dobey | barry: that also sounds familiar :) | 20:57 |
| hallyn | anyone know of a wait option or wait-like call to detect if task is zombie (without parsing /proc/$$/stat{,us}) ? | 20:57 |
| * barry thinks we need a lemmecheatstr for py3 | 20:58 | |
| zyga | hehehe | 20:59 |
| zyga | barry: would that be bytes | str magic wrapper? | 20:59 |
| barry | zyga: exactly, but you'd only be able to use it after 3 days of non-stop porting pain | 20:59 |
| zyga | barry: we can also wait for economy to win | 21:00 |
| zyga | barry: stuff that's too hard to port or not maintained will be replaced | 21:00 |
| * zyga mumbles something about our new ruby on rails overlords | 21:00 | |
| zyga | ;) | 21:01 |
| * slangasek points out that the last typewriter factory closed this decade | 21:01 | |
| barry | zyga: is that like, "wait long enough and nothing matters" | 21:01 |
| slangasek | the long tail is a ribbon covered in ink | 21:01 |
| zyga | ok, the package seems to work | 21:02 |
| zyga | the rest are upstream bugs on sdist that I'll fix tomorrow | 21:03 |
| * zyga pushed new plainbox packaging to launchpad | 21:11 | |
| zyga | and updated the recipe | 21:15 |
| zyga | roadmr: still working? | 21:17 |
| zyga | roadmr: I'd like to crate a vagrant environment for running SRUs from the daily ppa | 21:17 |
| zyga | roadmr: a vanilla image that adds the ppa and installs/updates the package | 21:18 |
| roadmr | zyga: yes, it's only 4:20 PM here :) | 21:18 |
| zyga | roadmr: + some testing on what we get from that | 21:18 |
| zyga | roadmr: would you like helping me on monday? | 21:18 |
| zyga | roadmr: oh | 21:18 |
| roadmr | zyga: sure, I can help! | 21:18 |
| zyga | roadmr: basically, a new directory with Vagrantfile | 21:18 |
| zyga | roadmr: that just deploys plainbox from the ppa and gives us ssh | 21:18 |
| roadmr | zyga: so we'd be using a cloud image as the base still? | 21:18 |
| zyga | roadmr: yes | 21:18 |
| zyga | roadmr: let's start with precise for simplicity | 21:19 |
| zyga | roadmr: we'll have some churn over the next few days to add 'plainbox sru' command | 21:19 |
| zyga | roadmr: and that's the test target | 21:19 |
| roadmr | zyga: ok | 21:19 |
| zyga | roadmr: thanks | 21:19 |
| zyga | roadmr: I should really be going | 21:19 |
| zyga | roadmr: if you want plainbox debs built locally | 21:19 |
| zyga | roadmr: I can give you a quick recipe | 21:19 |
| roadmr | zyga: sure, I usually use sbuild for that but if this is quicker it's ok | 21:20 |
| zyga | roadmr: http://pastebin.ubuntu.com/5597142/ | 21:20 |
| zyga | roadmr: that's crude, just branch checkbox and plainbox-packaging and update those paths | 21:20 |
| roadmr | oh neat! | 21:21 |
| zyga | roadmr: then build.sh builds subsequent attempts | 21:21 |
| zyga | roadmr: if you need to change anything in packaging, commit, otherwise it gets ignored | 21:21 |
| zyga | (in the packaging) | 21:21 |
| zyga | roadmr: try getting vanilla precise and installing that package | 21:21 |
| zyga | roadmr: if you get an MP for that vagrantfile I'll gladly review that | 21:21 |
| roadmr | ok sounds fun | 21:21 |
| zyga | roadmr: I rewrote all packaging and it should work now | 21:22 |
| roadmr | zyga: does the packaging branch still live in github? | 21:22 |
| roadmr | it lives!! | 21:22 |
| zyga | no | 21:22 |
| zyga | we moved it to lp:~checkbox-dev/checkbox/plainbox-packaging | 21:22 |
| roadmr | oh awesome :) | 21:22 |
| zyga | I pushed rev3 | 21:23 |
| zyga | (that was squashed with git, I had ~70 revisions like "snapshot" before I got this right) | 21:23 |
| roadmr | haha snapshots ftw | 21:23 |
| zyga | roadmr: https://code.launchpad.net/~checkbox-dev/+recipe/plainbox-daily | 21:24 |
| zyga | roadmr: I've queued builds to see what I got wrong | 21:25 |
| zyga | roadmr: but it builds for me | 21:25 |
| zyga | roadmr: though, not in pbuilder, I was too lazy | 21:25 |
| zyga | roadmr: if you can check it in sbuild that'd be great too | 21:25 |
| roadmr | zyga: hahah :) use sbuild! it's 3 commands to set up | 21:25 |
| zyga | roadmr: I need to take a break | 21:25 |
| zyga | roadmr: thanks for the help | 21:25 |
| * zyga EODs at 22:25 | 21:25 | |
| roadmr | zyga: good night :) | 21:26 |
| === salem_ is now known as _salem | ||
| === vorian is now known as v | ||
| zyga | barry: is it sane for python3 only package to build-dep on python2-minial to get pyversions which it is _not_ using as needed by python_distutils.pm, see: http://paste.ubuntu.com/5597227/ at line 851 | 21:57 |
| ScottK | zyga: No | 21:57 |
| zyga | ScottK: is that a build system bug? | 21:58 |
| ScottK | It's a lack of python3 support in debhelper. | 21:58 |
| zyga | ScottK: shouldn't debhelper then depend on python2-minimal? | 21:59 |
| ScottK | No. | 21:59 |
| barry | pybuild perhaps | 21:59 |
| ScottK | You only need it if you are building something for python. | 21:59 |
| ScottK | I think you're solving the wrong problem. | 21:59 |
| zyga | barry: you mean switch to --buildsystem=pybuild? | 21:59 |
| zyga | ScottK: well, as the pastbin shows: it fails to build, and I'm building a python3 only app | 22:00 |
| barry | zyga: that's probably the way to go in the long run, yes | 22:00 |
| barry | zyga: sorry, i am just slammed right now, with only a day and an hour of work time before pycon :/ | 22:00 |
| zyga | barry: thanks, sorry | 22:00 |
| * roadmr pops up his ears | 22:00 | |
| ScottK | zyga: build system distutils doesn't know about python3. | 22:01 |
| zyga | ScottK: I'm not sure how that works, where does --with=python3 come from? I'm trying to see what's missing the dependency - our package or part of the build system | 22:01 |
| ScottK | zyga: Where's the package? | 22:01 |
| ScottK | (or pastebin your debian/rules) | 22:02 |
| zyga | ScottK: the code is in lp:~checkbox-dev/checkbox/plainbox-packaging | 22:02 |
| zyga | roadmr: could you pastebin that please? | 22:02 |
| * zyga is on a tiny netbook where any browser hurts | 22:02 | |
| zyga | (which is ironic given the name) | 22:02 |
| zyga | ScottK: that's only the debain package mind you, the code is in lp:checkbox (in the plainbox directory) | 22:02 |
| roadmr | zyga, ScottK : http://paste.ubuntu.com/5597238/ | 22:02 |
| zyga | s/debain/debian/ | 22:03 |
| ScottK | zyga: Here's one that works - http://paste.ubuntu.com/5597241/ | 22:04 |
| zyga | ScottK: sorry, what does that mean? | 22:05 |
| ScottK | Don't use dh_auto_build/install | 22:05 |
| zyga | oh | 22:05 |
| ScottK | Since DH doesn't konw about python3, auto_* will not DTRT. | 22:05 |
| zyga | would adding --without=python2 be appropriate? | 22:05 |
| ScottK | No | 22:05 |
| zyga | ok | 22:05 |
| * zyga is very confused about how that all works but that's fine | 22:05 | |
| zyga | roadmr: ^^ | 22:05 |
| zyga | roadmr: so I guess we can drop dh_auto_{build,install} and do that manually | 22:06 |
| zyga | roadmr: if you can try to solve that and push the packaging branch that'd be a good EOD :) | 22:06 |
| ScottK | Note that there's no need to do per python3 version build/install for pure python3 code. | 22:07 |
| zyga | oh | 22:07 |
| zyga | that's cool | 22:07 |
| zyga | so we can drop most of the complexity | 22:07 |
| zyga | thanks for the tip! | 22:07 |
| roadmr | zyga: ok I can try :) | 22:09 |
| zyga | roadmr: thanks | 22:09 |
| zyga | roadmr: the build script should help you do that quickly, then you can check sbuild for correctness | 22:09 |
| roadmr | zyga: anyway my raring sbuild complained that python2-minimal is not installable ;( | 22:10 |
| micahg | there's python-minimal and python2.7-minimal | 22:12 |
| micahg | though in raring, I don't think you'd want either | 22:13 |
| ScottK | Certainly not for a python3 application. | 22:17 |
| === fisted_ is now known as fisted | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!