=== wedgwood is now known as wedgwood_away [00:31] 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 === 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 [02:53] roaksoax: which release is this dist-upgrade happening in? [02:53] roaksoax: ah, n/m, found at the bottom of your pastebin [02:54] roaksoax: so, why are you using a Conflicts: against tftpd-hpa, instead of a Breaks:? [02:55] slangasek: cause i thought conflicts would be more rrstrictive [02:55] so both services dont run at the same time [02:56] slangasek: btw upgrade candidates can be found at ppa:maas-maintainers/stable [02:56] 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:59] roaksoax: ok, I can't convince myself that Breaks: tftpd-hpa would be more correct than Conflicts:, so let's set that aside [03:00] 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] slangasek: yeah i was thinking on changing that [03:00] 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] slangasek: i tried taht and disnt make apt happy unfortunately [03:01] ok [03:01] but i could give it another try [03:01] is the 'cobbler' package installed in this scenario? [03:02] Well, I guess maas-provision is more likely [03:02] slangasek: yeah maas-provision [03:03] 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] this may be why apt considers it better to remove maas instead of removing tftpd-hpa [03:03] sorry, dinner [03:06] 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 === Ursinha_ is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [04:04] has anyone here used valgrind's memcheck tool successfully on any glib/gtk app? [04:04] it always seems to have a ridiculous amount of rubbish from gtk/glib's internals [04:05] There's a suppression file for that IIRC [04:05] only one I found was from really old wxWidgets wiki [04:05] RAOF: iirc that was last updated in 2009. [04:05] hyperair, ask in #gtk on gimpnet :) [04:07] heh [06:08] Godo morning [06:13] pitti: Godot morning! [06:14] RAOF: hohow are yohoow? [06:16] slangasek: hey Steve, still here? [06:16] 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) === ewindisch_ is now known as ewindisch === asac` is now known as asac [07:48] good morning === smb` is now known as smb [09:07] utlemming: hey [09:23] arges: Hi, regarding iptables, why haven't also fixed the debian-changes things as described by me in the bug report? Just curious. [09:29] mdeslaur: I am sorry about that =) i did think "i bet mdeslaur thinks openssl is his package only by now ;-)" [09:35] hyperair: yes, I remember seeing a memory leak via a glib routine [09:35] arges: could you accept/evaluate/sync systemtap 2.1 from Debian? bug #1130626 now has pbuilder log as well [09:35] bug 1130626 in systemtap (Ubuntu) "Update Ringtail SystemTap to 2.1" [Undecided,New] https://launchpad.net/bugs/1130626 [09:36] vibhav: did you use a suppresion file or anything? valgrind's output is typically pretty polluted when used on a glib program [09:36] No [09:36] hyperair: I will try one right now [09:37] There are some glib routines which were leaking memory [09:37] s/are/were/ [09:38] hyperair: Is there a specific suppresion file? [09:38] 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:39] Indeed [09:41] oh interestingly it seems pretty clean now [09:41] =O [09:42] just some warninsgs from cairo [09:46] 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] mdeslaur: I was thinking of preparing precise upload for my two bugs as well. [10:08] xnox: Please do upload your openssl changes to precise as well, yes. [10:08] infinity: yeah, testing. [10:08] 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:09] * infinity goes back downstairs to ingest more beer. [10:09] infinity: for quantal, yesterday I did run full testsuite & benchmarks on nexus7, all was fine. [10:09] infinity: repeating for precise now. [10:09] infinity: it's armv4 assembly from way back when ;-) [10:09] xnox: Can you do some realworld things like a local apache2 w/SSL and abuse it a bit to see if it DTRT? [10:10] infinity: i do wonder if the elliptic curves optimisations will work on arm64 as well =))))) [10:10] 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] infinity: well it was tested in raring =)))) [10:10] xnox: FSVO "tested". [10:10] =)))))))))))))) [10:10] xnox: We don't have that many people abusing openssl on ARM in raring, I suspect. [10:10] apart from hrw =) [10:15] 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] xnox: i. e. indicator-session is missing [10:15] (adding it now) [10:15] pitti: I did not finish the debian grep, jdstrand did launch ubuntu grep. Will take some time to get the results back. [10:16] ack [10:16] ah, it seems indicator-session tries the org.gnome.SessionManager first, and then fall back to CK [10:16] so fixing gnome-session ought to help actually; doing that now [10:18] I have a canonistack instance set up to try and get codesearch working for Ubuntu [10:18] but I haven't figured out how to work it yet; documentation is quite lacking [10:18] ah bummer, our gnome-session needs logind >= 183 [10:18] Laney, it's easier to just do that from the datacenter [10:18] just do what? [10:19] Laney, grep the archive [10:19] I'm talking about setting up http://codesearch.debian.net/ for Ubuntu [10:19] oh, ok [10:19] * pitti used http://people.canonical.com/~pitti/scripts/for-srcarchive on lillypilly before (that has a local mirror) [10:19] right [10:19] Laney, I though you wanted to do a one time grep, not to set up a service for those ;-) [10:19] Laney, good luck [10:20] https://github.com/debiancodesearch/dcs/blob/master/README [10:20] not so detailed ;-) [10:20] Laney: ISTR jodh was a fan of this aswell [10:20] excellent, it's a great service [10:21] I will get around to asking the developer for better instructions [10:22] actually I'll do it now while I'm thinking about it [10:22] tumbleweed: will you upload pyxdg? :) [10:25] 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:26] jodh: You just sold it to me :) [10:26] yeah I'm not sure debiancodesearch has anything like that [10:28] 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:29] Interesting. [10:29] Whilst we are talking of developer resource tools, xnox - how is your snapshot equivalent thing going? :) [10:30] Daviey: submerged in the todo list =) [10:31] 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:32] xnox: lcy01 and lcy02 run different versions of openstack.... what tooling are you using to converse with them.. maybe there is a bug? [10:33] Daviey: interesting. I'm using juju 0.6.0.1. [10:33] with openstack providers I believe. [10:34] xnox: check in with hazmat, he might know the situation [10:34] Daviey: thanks. [10:38] what's the idea there? exposing the librarian somehow or running an actual snapshot equivalent? [10:41] 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] Laney: librarian... store valid Packages.gz as time snapshots, but proxy through to librarian AIUI [10:41] right [10:43] then write a deb-bisect? :) [10:46] Laney: the interested parties can do that then, yes ;-) [10:47] * Daviey fains disinterest [10:48] i suppose it would be apt-bisect [10:52] infinity: apache bench stress tests?! =) [11:01] slangasek: done, https://bugs.freedesktop.org/show_bug.cgi?id=62016 [11:01] Freedesktop bug 62016 in daemon "pkexec does not apply PAM's environment" [Normal,New] [11:08] so will 13.04 have still amazon search enabled by default? [11:10] sonne: yeah. also see smart search blog post from Allen Bell about the improvements that are planned there. [11:10] sonne: this is more of a #ubuntu-desktop question though ;-) [11:10] xnox, alan? [11:11] i can't seem to be able to find the blog post you're mentioning *shrug* [11:11] thanks for answering my question though :) [11:12] sonne: http://www.theopensourcerer.com/2013/01/ubuntu-smart-scopes/ [11:12] cheers [11:12] xnox, sonne, this won't be in 13.04 though [11:13] xnox, sonne, this has been discussed during the UDS session about it two days ago. [11:13] that's too bad [11:13] sonne, I know :) [11:14] davidcalle: hehe =) i missed that session. Oh well. Or see latest UDS where things got redefined then ;-) [11:14] would have been a nice improvement for the search problem [11:15] 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:17] 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:18] davidcalle, personally i'd rather have the user decide whether or not to have searches on the internet on installation [11:19] or some kind of other solution that would not have the user go and google how to disable the searches [11:19] but then, i have no clue on how the whole thing is being handled :) [11:21] sonne, I don't know, I think that the settings > privacy > on/off switch is a good design. [11:23] 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:24] maybe adding a "" right there would be the best to try and protect the most inexperienced (or laziest :) users [11:28] sonne, there is a discoverability issue of that setting, that's true. Hopefully, it will evolve into something most users are happy with :) [11:30] 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:34] 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:35] sonne, I actually have no idea about the Vala ones. I guess you could ask that to pstolowski in #ubuntu-unity. [11:36] thanks for the pointer :) [11:36] sonne, np :) [11:38] utlemming: around? [11:39] 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:42] zyga: ah, you want to update it in collab-maint? [11:42] pitti: yes but I don't know how [11:42] pitti: I got the upstream git tree, I've exported 1.0.6 from the tag [11:43] pitti: I've got the debian collab-maint tree as well [11:43] oh, debian's git-buildpackage trees are not based on upstream git [11:43] you usually just run git-import-orig to import a new tarball [11:43] yeah, but I needed both to get the pristine tarball, apparently upstream builds none [11:43] ah, sure [11:44] trying [11:44] woot [11:44] worked! [11:44] let me build and check this [11:44] so what happens if it works? [11:44] can you help me push 1.0.6 to debian git and sync that to ubuntu somehow? [11:44] https://github.com/mitchellh/vagrant/tags ? [11:45] zyga: yes, I can [11:45] zyga: NB that vagrant currently has some ubuntu modifications [11:45] yes [11:45] zyga: if they are applicable to Debian they should be committed there; or are they obsolete? [11:45] I saw two patches [11:46] one seems to change the location of common files, it just places /usr/share/vagrant there, seems okay [11:46] 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:47] but that was integrated upstream earlier [11:47] so perhaps it's no longer in the debian git tree [11:49] creating pbuilder base image [11:49] * zyga needs to grok all the packaging stuff better [12:05] Hi guys, how do i ask for the creation of a package + addition in repo for ubuntu? [12:07] rmannibucau: perhaps yuo are interested in #ubuntu-app-devel and developer.ubuntu.com? [12:08] zyga, i'll conect, thanks [12:09] 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] 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] zyga: perhaps there's a way to disable cowdancer and just use classic tarballs and temp dirs? [12:10] ah, I can just try building the package [12:15] so that worked [12:16] woot, cool, let me check if the package works === MacSlow is now known as MacSlow|lunch [12:17] pitti: assuming this works, what should I do next? [12:25] 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] zyga: ^ [12:25] ~/public_git on git.d.o is nice [12:27] Laney: I don't have access to git.debian.org most likely, yet [12:27] pitti: ok, let me try that [12:28] well you can sign up, but github/gitorious/whatever also works === dholbach_ is now known as dholbach [12:29] my ssh key does not work with people.ubuntu.com, I'll try people.canonical.com [12:29] apparently lillypilly has git installed too, so perhaps you can actually push there! [12:30] lillypilly? [12:30] people.c.c [12:30] oh [12:31] yeah [12:32] pushed to http://people.canonical.com/~zyga/vagrant.git/ [12:32] xnox: you do know I was just kidding, right? :) [12:32] xnox: I'll wait a week, no rush [12:34] I gave the new vagrant a run here [12:34] with fresh cloud images from cdimage.ubuntu.com === _salem is now known as salem_ [12:34] let's see how that goes [12:39] hmm [12:39] failed to up vms? [12:39] odd [12:50] * zyga goes for lunch [13:01] mdeslaur: i'd rather you not wait a week though =) as your bug is high priority and mine are not. [13:03] 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:04] mdeslaur: yeap. Finished amd64 test, only armhf test left before uploading precise debdiff. [13:05] xnox: could you please add this? http://paste.ubuntu.com/5595873/ [13:05] 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:06] mdeslaur: looks ok to me. [13:06] xnox: here's my quantal debdiff: http://paste.ubuntu.com/5595877/ [13:06] awesome, let me work those in ;-) [13:06] xnox: thanks! [13:06] xnox: sorry for colliding with you :) [13:07] mdeslaur: your bug report does not follow https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template though [13:07] oh! right, I didn't update it yet...wait a sec [13:07] can you apply your awesome editorial skills to bug 1066032, please? [13:07] bug 1066032 in openssl (Ubuntu Quantal) "Deadlock when reading a public key" [High,Confirmed] https://launchpad.net/bugs/1066032 [13:08] ok. cool. [13:13] xnox: done, thanks [13:14] cool =) [13:46] 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:49] xnox: http://people.canonical.com/~jamie/consolekit/ [13:50] pitti, ^ [13:50] jdstrand, hey, thanks for the grepping ;-) [13:54] np [13:57] infinity: do you have an apache2 merge planned soon? === MacSlow|lunch is now known as MacSlow [14:06] 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] seb128: I am the TIL on ubuntu-geonames. [14:06] seb128: what's up? [14:07] xnox, pgraner reported https://bugs.launchpad.net/ubuntu-geonames/+bug/1150109 [14:07] Launchpad bug 1150109 in Ubuntu Geonames "Ubuntu's geonames only knows about Hong Kong in Guyana, not in China" [Undecided,New] [14:07] seb128: we take straight database from http://www.geonames.org/ [14:07] 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] xnox, but geonames.org lists Hong Kong China [14:08] it's even the first entry [14:08] xnox, http://geoname-lookup.ubuntu.com/?query=hong%20kong doesn't [14:08] seb128: they have full db, we have only free/small db. [14:08] seb128: but it is weird in deed. [14:08] xnox, well, Hong Kong is not really small ;-) [14:08] we should have it in our db [14:09] seb128: yeah, I'll debug it here locally, assign that bug to me plese. [14:09] xnox, thanks [14:10] (done) [14:19] 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:23] smoser: Don't you just need to LD_PRELOAD it? [14:23] My suggestion to psusi was to put it in in-target, in debian-installer-utils [14:23] For prototyping, just edit stuff on the fly in the running installer [14:25] Grr, where oh where did I put my secondary backup disk [14:25] 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] 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:26] in-target won't affect debootstrap but will handle the bulk of everything else. [14:26] * xnox really had no chances =)))) [14:26] works fine now. [14:26] maybe i'll just patch the initramfs launch of the installer. [14:26] Please don't. Use in-target [14:27] smoser: I've had stuff spuriously failing with eatmydata, due to things not being present when there were expected to be already. [14:27] Indeed, I do not want this to e.g. interfere with partitioning in some way [14:27] It should be constrained to operations on the target system [14:27] hm.. [14:28] 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] anyway. [14:28] You'll have to do it in a couple of places but that's no big deal [14:33] 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:44] zyga: man debhelper, see common buildsystem options to specify "src" directory. [14:45] xnox: thanks! [14:46] zyga: so you'd need to override_dh_auto_[build|configure|install|test]: with dh_auto_build --sourcedirectory=subdir1/component/plugin/ [14:46] no, you can pass options to dh [14:46] zyga: I had a hack somewhere to auto strip override_ prefix, to have all four targets. [14:46] zyga: dh --sourcedirectory=foobar shoudl work, but it didn't in the past. [14:47] hmm [14:47] I was just looking at that and wondering if there's DH_OPTIONS that could get that somehow, let me keep trying [14:47] I think that happens through DH_OPTIONS magic [14:48] ah, DH_INTERNAL_OPTIONS [14:50] I'm planning on patching in-target as cjwatson suggested [14:50] smoser: ^ [14:50] 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:56] psusi, you know that you can easily patch an initramfs by just appending a gzipped cpio to it, right? [14:56] 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] For experimentation it's way easier to just edit on the fly [14:57] have to patch the cd to include eatmydata anyhow [14:57] 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] psusi, you can just shove it insto the initramfs, no? [14:57] smoser: no, needs deb [14:57] well, maybe [14:58] I guess a udeb wouldn't be a terrible idea [14:58] smoser: no, it needs installed into the target system ;) [14:58] udeb shouldn't be needed since it isn't intented for the installer to use right? just the target [14:59] depends on whether it's easier to invoke it in the chroot or not [14:59] 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] BTW building CDs for this is a mug's game - use netboot for testing, it's way faster [14:59] with a local mirror anyway [14:59] hrm... have to set up a local mirror then... [15:00] psusi, squid proxy is simpler there i think. [15:00] figured it would be easier to just download and modify the cd than to download and setup a local mirror... [15:01] anyway, psusi i'm interested in your progress there. [15:01] http://smoser.brickies.net/git/?p=tildabin.git;a=blob;f=overlay-initramfs;hb=HEAD [15:02] thats my "overlay-initramfs" if you're interested. it just makes patching an initramfs (possibly) simpler. [15:05] slangasek, system-config-printer 1.3.12+20130308-0ubuntu1 uploaded. [15:10] 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:16] OdyX, only Ubuntu-specific which I have in foo2zjs is that printer-driver-foo2zjs depends on mscompress. [15:18] tkamppeter: I have handled that difference specifically in my uploads to Debian experimental. === kentb-out is now known as kentb [15:19] tkamppeter: granted, my changelog entry was backwards (now corrected), but I made my possible to reduce your work. :) [15:41] OdyX, great, thank you. [15:41] tkamppeter: my pleasure. [15:42] 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:43] slangasek: i think that would be the only option [15:51] hello all , i am not sure if this is the right place to ask but i couldn't find a better place [15:51] hello , could someone help me understand cgroup cpuacct [15:51] i had a few specific queries [15:52] the cpuacct.usage displays the number of nano seconds used by the cgroup [15:52] and the stat shows nett and user usages [15:53] how are these 2 related , and say i wanted to compute the net cpu utilization of a cgroup how would i do that ? [15:57] slangasek: so basically, make maas-provision binary not depend on anything and not install anything either? [15:59] slangasek, hi [16:00] tkamppeter: can you prepare a cups-filter 1.0.30-1 upload to Debian experimental ? [16:02] OdyX, I will do it, I am currently only putting in the last packages for Ubuntu FF. [16:03] 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] bug 923955 in qpdf (Ubuntu) "pdftopdf filter fails to output form field values" [Undecided,Confirmed] https://launchpad.net/bugs/923955 [16:05] slangasek, can you also sync foo2zjs_20130306dfsg0-1 from debian/experimental? OdyX has uploaded it now and it contains important bug fixes. [16:08] jdstrand, seb128: archive grep> thanks! [16:10] 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:11] 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:15] slangasek, thanks. [16:15] pitti: sure thing :) [16:15] pitti, can you sync qpdf from experimental for me? === Ursinha-afk is now known as Ursinha [16:16] slangasek, foo2zjs I will sync by myself then, it only needs to arrive in the Debian archives. [16:16] tkamppeter: done [16:16] 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] too late :) [16:16] tkamppeter: snap. pitti is quick =) [16:17] OdyX, how long does it take until your foo2zjs from today gets syncable for Ubuntu. [16:17] xnox, thanks anyway. [16:17] pitti, thanks for syncing. [16:17] tkamppeter should apply for upload rights to printing stuff [16:17] tkamppeter: I got the "UPLOADED" mail minutes ago, I suspect something in the range of hours, at most. [16:18] 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] 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:19] OdyX, the Ubuntu syncpackage still found only 20130303dfsg0-1 and not 20130306dfsg0-1 [16:19] 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] (look for latest upload, if stuff is in experimental) [16:20] tkamppeter: it's currently being built on the buildds so I guess it's "soon" now ;) [16:20] xnox, thanks. [16:23] tkamppeter: it might be useful for Ubuntu to sync foomatic-db 20130301 too [16:23] OdyX, I have already updated to 20130308. [16:25] 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:26] mdeslaur: I can do one. [16:26] infinity: ok, thanks [16:27] slangasek: yeah the dummy package seems to do the trick! Thanks :) I would have never thought about that :) [16:31] slangasek: but i think the other option would simply be to remove tftpd-hpa as a recommends of maas-provision [16:31] that would introduce less change [16:45] hi there… [16:45] I have a "little" problem [16:46] 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] Alt+Tab, Windowskey or so on [16:46] once it works… it runs solid [16:49] and no logentries whatsoever [17:07] stokachu: bug 578536 is being removed from lucid-proposed. because it has not been verified in a timely fashion. [17:07] bug 578536 in autofs5 (Ubuntu Lucid) "when stopped, automount orphans some mounts" [Medium,Confirmed] https://launchpad.net/bugs/578536 [17:07] stokachu: i'd think we care about it ^ [17:07] xnox: yep already spoke to bdmurray about it [17:07] stokachu: is that ok or not? [17:07] yea [17:08] i personally care but the ones affected by it have since migrated to precise [17:08] stokachu: oh, nice fair enough =) [17:08] thanks for the heads up :P [17:09] stokachu: I wish you'd idle on #ubuntu-release =) this is were I noticed it. [17:10] 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:11] 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:15] roaksoax: as long as that's a reasonable change, and has the intended effect, sure [17:17] seb128: I'm not sure if you saw my lightning talk but https://errors.ubuntu.com/?user=desktop-packages [17:18] bdmurray, no, I didn't, that's nice! [17:18] he was to distracted by the comics :) [17:18] lol [17:18] seb128: so those are all the packages that that launchpad team is subscribed to [17:18] 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] heh [17:19] * ogra_ never runs hangouts on his laptops ... [17:19] but thats just googles fault ... not providing it for arm :) === rickspencer3_ is now known as rickspencer3 [17:29] ogra_: with what's going on you may not need a plugin soon [17:29] hopefully [17:30] * zyga wonders how to use two buildystems listed by dh --list at the same time [17:30] I want python3 and sphinxdocs [17:33] these are not buildsystems, but plugins — you can use "dh --with python3,sphinxdoc" [17:35] ah [17:35] thanks [17:35] the man page was confusing [17:41] hmm, it seems that dh --sourcedirectory is ignored by dh_sphinxdoc [17:41] or I'm doing it wrong, passing --sourcedirectory to dh [17:41] Is that an option to dh_sphinxdoc or to dh? [17:42] to dh [17:42] how is dh_sphinxdoc ignoring it? [17:42] geofft: to dh [17:42] does the source directory matter to dh_sphinxdoc? [17:42] mitya57: it's not finiding any docs, this is a perfectly standard python3 + setup.py + sphinx package [17:43] dh_sphinxdoc cleans up things that have been dh_installed [17:43] _or_ I may misunderstand what I need to do [17:43] like build docs explicitly [17:43] but that's not specified so I don't know [17:43] dh_sphinxdoc doesn't build docs [17:43] oh [17:44] that's confusing then, ok, let me see if I can build docs explicitly [17:45] zyga: there's nothing in dh_sphinxdoc's manpage that makes me believe it would build docs [17:45] tumbleweed: apart from the obvious name that suggest otherwise [17:46]