| === pgraner-afk is now known as pgraner | ||
| pitti | Good morning | 04:24 |
|---|---|---|
| === Kk2 is now known as kk2 | ||
| dholbach | good morning | 06:42 |
| === luist_ is now known as luist | ||
| jibel | hallyn, thanks for looking. What was the problem with memsw.limit_in_bytes? I had to enable is with swapaccount=1 on the boot command line. Anyway, I'll try to reduce the test case on a fresh installation. | 08:18 |
| === doko_ is now known as doko | ||
| === halfie|afk is now known as halfie | ||
| bigon | hi, is that expected that rmadison tool is still showing me packages from hardy? | 10:04 |
| === dholbach_ is now known as dholbach | ||
| xnox | bigon: probably just not removed from the rmadison config..... | 10:20 |
| === oSoMoN_ is now known as oSoMoN | ||
| xclaesse | seb128, (sorry if it's not you to ping): gnome3 ppa has libharfbuzz-icu0 package but no corresponding -dev | 10:30 |
| seb128 | ricotz, ^ | 10:30 |
| xclaesse | something went wrong in the split of icu out of harfbuzz I guess | 10:31 |
| ricotz | xclaesse, the libharfbuzz-dev packages contains the needed dev bits | 10:35 |
| ricotz | xclaesse, i wasn't involved in the split, but it is fine that way | 10:36 |
| xclaesse | ricotz, hmmm, indeed... wondering why my webkit build does not find it then :/ | 10:37 |
| xclaesse | probably confused between distro package and what's in jhbuild :( | 10:37 |
| doko | mlankhorst, mdeslaur: you looked last at libx11 and libxcb. could you have a look at the build failures in the test rebuild? and/or decide on the merge from debian? | 10:37 |
| xclaesse | thanks anyway :) | 10:37 |
| ricotz | xclaesse, probably make sure you have libicu-dev installed and maybe even enable the harfbuzz-confflag explicitly | 10:40 |
| cjwatson | bigon: I've removed hardy and oneiric from rmadison, thanks | 10:41 |
| mlankhorst | sure | 10:45 |
| === vibhav is now known as Guest99035 | ||
| === Sweetsha1k is now known as Sweetshark | ||
| === MacSlow is now known as MacSlow|lunch | ||
| tseliot | pitti: hi, can you approve nvidia-graphics-drivers-319-updates in saucy please? | 11:31 |
| pitti | hey tseliot | 11:38 |
| pitti | tseliot: approve for NEW, presumably? it's been a while since I've done archive admin, let me look | 11:38 |
| pitti | tseliot: did the packaging or license change compared to the previous versions? | 11:39 |
| tseliot | pitti: yes, new and then please move the binaries to main | 11:39 |
| pitti | tseliot: restricted, I presume? | 11:39 |
| tseliot | pitti: not really, it's the same as the 319 flavour | 11:39 |
| tseliot | pitti: yes restricted | 11:40 |
| pitti | "same as 310"? | 11:40 |
| pitti | oh, 319 without updates | 11:40 |
| tseliot | yep | 11:40 |
| tseliot | 319 replaces 310 | 11:40 |
| * pitti gives that some spot-checking and comparing with -319 | 11:41 | |
| pitti | tseliot: LGTM, source-NEWed | 11:44 |
| tseliot | pitti: excellent, thanks! | 11:45 |
| pitti | cjwatson, xnox: I'm currently experimenting with letting DanChapman's ubiquity autopilot tests run in a VM with xvfb; before I get to that, I need to provide it with a fake disk drive, so that it has something to install to | 11:47 |
| pitti | I created a 5 GB loop device and put a raid0 on top of that, getting a /dev/mdX; that bit works fine | 11:47 |
| cjwatson | I think it will probably need to look a bit more like a regular disk | 11:48 |
| cjwatson | Maybe virtio instead? | 11:48 |
| pitti | is there a way to hide the other, "real" /dev/vda from partman's consideration? | 11:48 |
| pitti | right now, if I do it like that and install in automatic mode, it trashes the (mounted!) /dev/vda, partitions/overwrites it, and fails | 11:48 |
| pitti | with manual partitioning to /dev/md42 it works | 11:48 |
| xnox | pitti: providing fake disks to the installer and hiding host/VM disk, is something i have not managed to do yet. If this was possible, we'd be able to fully automate installer tests in lxc or somesuch =) | 11:49 |
| pitti | xnox: well, we have the smoketests, but they use pre-seeding; it would be cool to run the ubiquity UI tests with autopilot | 11:49 |
| pitti | we don't need to actually boot the installed disk, of course | 11:49 |
| cjwatson | There isn't a general filter mechanism, short of diverting parted_devices or something | 11:49 |
| pitti | just a coarse inspection that the partitioning is right should be enough for the UI tests | 11:50 |
| xnox | pitti: yeah, my current plan was to further modify ubiquity pre-seeding to self launch itself under autopilot, instead of using preseed-file to automate itself. | 11:50 |
| xnox | (if above makes sense) | 11:50 |
| cjwatson | (Which isn't necessarily *completely* stupid; divert it, call the real one and grep out the devices you don't want ...) | 11:50 |
| doko | barry, you uploaded python-configglue, without a MIR for python-configparser | 11:50 |
| pitti | cjwatson: that seems fine | 11:50 |
| pitti | it's a bit of a bugger that it defaults to a mounted device, but I guess that doesn't happen in real life | 11:51 |
| doko | zul: you uploaded python-greenlet without a MIR for python-all-db | 11:51 |
| pitti | cjwatson, xnox: I also need to divert grub-install for that, as my fake /dev/md42 isn't visible by grub; diverting /usr/sbin/grub-install doesn't work, though, as it calls grub-install from /target; did any of you already run into this? if not, I'll look for a workaround | 11:52 |
| cjwatson | There are various mechanisms for avoiding the installation medium, avoiding things that are part of dmraid, and the like, but the above isn't one of them | 11:52 |
| pitti | we can of course also set up a custom VM with a spare virtio drive | 11:52 |
| cjwatson | I'm concerned that by the time you've worked around all the problems with this it won't look enough like a real environment | 11:53 |
| pitti | but I wanted to check if we can do it in a bog standard autopkgtest VM, which would be easiest (also for reproducing problems, etc.) | 11:53 |
| cjwatson | The installer is pretty sensitive to details of disk layout | 11:53 |
| doko | zul, ahh, a typo. fixed. thanks for testing the build deps before upload ;) | 11:53 |
| cjwatson | For GRUB, I'm not sure, what would you do instead if you can't see /dev/md42? | 11:54 |
| doko | zul, python-keystoneclient and python-warlock ftbfs | 11:55 |
| pitti | cjwatson: I'm not sure what grub-install considers as "see", but its current behaviour is quite alright; I'm mostly checking if we can skip the bootloader install. That's possible in manual mode of course | 11:55 |
| pitti | (or brainwash grub-install to accept /dev/mdX anyway) | 11:56 |
| doko | jamespage, could you have a look at the maven mess? wants to get in main again, see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt | 11:56 |
| pitti | anyway, I'll play around with this a bit | 11:56 |
| pitti | cjwatson: thanks for the parted_devices trick | 11:56 |
| jamespage | doko, yeah sure | 11:57 |
| doko | jamespage, \o/ | 11:58 |
| jamespage | doko, hmm dom4j - lets see now | 11:58 |
| * jamespage goes to poke it with a big stick | 11:58 | |
| cjwatson | pitti: I guess it depends exactly how grub-install is currently failing | 11:59 |
| doko | Daviey, cjwatson, looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg, I see that only ruby-json has a MIR (just promoted) | 12:09 |
| cjwatson | We've been asking for MIRs for those for some time :-/ | 12:11 |
| rbasak | Daviey asked me to look at those last week. | 12:13 |
| rbasak | This does seem a bit backwards though. Is it normal to just bump a major version and cause a bunch of component mismatches without examining the situation first? | 12:14 |
| doko | rbasak, I think I do repeat myself here. getting puppet away from ruby1.8 was requested for the last *three* releases | 12:15 |
| doko | nothing did happen, so I did take the clue bat | 12:15 |
| cjwatson | rbasak: I'm wary of complaining about that aspect of it, since it's so easy to do by accident | 12:17 |
| cjwatson | But it does need to be sorted out | 12:17 |
| * rbasak will sort it out | 12:18 | |
| doko | thanks | 12:18 |
| === MacSlow|lunch is now known as MacSlow | ||
| doko | zul, Daviey: the apache2 merge cause a lot of packages to dep-wait. mdeslaur told me that you would care about it? | 12:20 |
| rbasak | doko: please remember that I'm new here. I wasn't aware of any communication about wanting puppet out of ruby1.8. I'd have happily tried a merge without bumping to puppet 3 first had I known about it. Might it be an idea to send a warning to ubuntu-devel or ubuntu-server before you take your clue bat out in future? | 12:20 |
| zul | doko: yeah ill take a look at it today | 12:21 |
| rbasak | doko: to say "X needs to be done; it hasn't been done, so I propose that I'll do Y unless I hear otherwise". | 12:21 |
| rbasak | doko: because had I seen that, I'd have looked at it. | 12:21 |
| doko | rbasak, well, I can try (and I didn't know that you were not involved with that earlier). but maybe people should be reminded at the various ftbs and component mismatch web pages at regular intervals | 12:22 |
| rbasak | doko: AIUI, puppet wasn't FTBFS nor component mismatching before your upload, though. Is there somewhere that I could have seen that you wanted the ruby1.8 dependency removed? | 12:23 |
| doko | rbasak, I don't know. had that mentioned several times at UDS'es in public sessions, so it should have some recording | 12:24 |
| rbasak | So I'm new to MIRs. ruby-hiera needs an MIR, but recommends mcollective, which I've found evidence is safe to drop with no consequences. Should I just upload a ruby-hiera delta that drops the recommends down to a suggests first before filing the MIR to resolve that issue? | 12:32 |
| === sraue_ is now known as sraue | ||
| rbasak | ie. do we do uploads to universe to get packages ready for main inclusion? | 12:35 |
| rbasak | (I presume so but I wanted to check) | 12:35 |
| xnox | rbasak: yeah. packages are promoted from universe/multiverse into main/restricted. Thus they should be in the archive already. | 12:37 |
| rbasak | OK, thanks! | 12:43 |
| dpm | seb128, ok, this is still WIP, but I've added the Launchpad setup instructions for new translatable projects, so that next time it's easier to find out how to do it -> https://wiki.ubuntu.com/Touch/CoreApps/Translations | 12:53 |
| dpm | it's for core apps, but it can apply to any LP project really | 12:53 |
| ev | mpt: is the count of machines what we're really weighting? I thought it was the errors themselves? That is, (min(days since first error, 90) / 90.0) for each error in the release / number of unique systems seen in the past 90 days in the release | 12:57 |
| ev | This is looking at "c = count of machines (eventually weighted)" | 12:57 |
| ev | (for the error rates of architectures in each problem) | 12:58 |
| seb128 | dpm, thanks! | 13:00 |
| mpt | ev, I think you need to weight both | 13:01 |
| mpt | The point of weighting a machine when counting it is to take into account the probability that it no longer exists, no matter what you then use that count for. | 13:01 |
| === oSoMoN_ is now known as oSoMoN | ||
| === _salem is now known as salem_ | ||
| ev | we create an awful lot of work for ourselves by not just counting systems running Ubuntu. | 13:04 |
| ev | mpt: so what would you weight the denominator with? | 13:04 |
| mpt | Even if we did count them, we'd still need to weight them in exactly the same way. :-) | 13:04 |
| ev | fair point :) | 13:05 |
| doko | pitti, there seems to be a bug in your dependency tracking code for component mismatches. shortens libc++ to libc ... | 13:05 |
| cjwatson | That's not pitti's code | 13:06 |
| cjwatson | Wait, unless I misunderstand. Which dependency tracking code do you mean? | 13:07 |
| doko | cjwatson, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 13:09 |
| doko | and it eats dashes too in the popups | 13:09 |
| doko | the txt files seem to be correct | 13:09 |
| hallyn | jibel: well I"m not sure. I had swapaccount=1 set in my grub.cfg, but it never seemed to honour that. kept getting EOPNOTSUPP | 13:11 |
| cjwatson | Wah, where on earth is libc++ in all of that | 13:12 |
| cjwatson | Oh, I see, that might be my fault | 13:13 |
| doko | on the top, the graph shows gmp depending on libc | 13:13 |
| doko | and unrelated, if you hover over the green circles, then the dashes are missing in the popups | 13:14 |
| mpt | ev, r(whatever) = ( Σ whatever (machine weight * errors in period / period) ) / ( Σ whatever (machine weight) ) | 13:16 |
| mpt | I doubt that's simplifiable | 13:17 |
| * xnox ponders about introducing LaTeX irc extensions..... | 13:17 | |
| ev | I maintain again: we need a whiteboard | 13:17 |
| ev | xnox: this thing doesn't even support unicode properly. | 13:18 |
| maswan | xnox: just write it out, the experienced reader will understand \frac{... | 13:18 |
| maswan | xnox: had a lecturer that provided lecture notes on the web in that form, was surprisingly readable. :) | 13:19 |
| ev | mpt: this looks completely different than the previous formula for weighting errors per calendar day. Was that method incorrect? | 13:19 |
| cjwatson | doko: Currently wishing I were a little bit more familiar with dot | 13:19 |
| mpt | ev, no, the difference between them is bug 1077122. :-) | 13:20 |
| ubottu | bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed] https://launchpad.net/bugs/1077122 | 13:20 |
| mpt | oh, we had a previous formula for *weighting* errors? | 13:20 |
| mpt | Oh, right, P = e ^ (–λ t) | 13:21 |
| ev | no, I think this is the confusion I have between bug 1077122 and bug 1069827 | 13:21 |
| ubottu | bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed] https://launchpad.net/bugs/1077122 | 13:21 |
| ubottu | bug 1069827 in Errors "Error rate incorrectly spikes with any influx of machines" [High,Confirmed] https://launchpad.net/bugs/1069827 | 13:21 |
| mpt | P = e ^ (–λ t) is just my prediction of what the weight curve will end up looking like | 13:21 |
| cjwatson | Looks like there might be an undocumented way to quote symbols | 13:22 |
| doko | didrocks, promoted sphinxbase n -proposed as well | 13:24 |
| mpt | ev, yeah, probably we should avoid using the word "weight" w.r.t. 1069827 ... that's a fudge | 13:24 |
| mpt | 1077122 is about the probability that a machine doesn't exist any more | 13:24 |
| didrocks | doko: thanks! | 13:25 |
| mpt | 1069827 is about the probability that a new reporting machine is representative of a large number of new not-yet-counted machines | 13:25 |
| * ev nods | 13:26 | |
| ev | that much I get, and it results in the formula you came up with and I coded with the following test: http://bazaar.launchpad.net/~daisy-pluckers/daisy/trunk/view/head:/test/test_weighting.py#L42 | 13:27 |
| ev | but what I don't get is how that connects to weighted machines or bug 1077122 | 13:27 |
| ubottu | bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed] https://launchpad.net/bugs/1077122 | 13:27 |
| mpt | aha, weight weight weight | 13:27 |
| doko | seb128, you synced jackd2 from experimental, now stuck in -proposed because of a component-mismatch (opus) | 13:27 |
| ev | I see a whiteboard, off in the distance | 13:28 |
| ev | but I bet people are precious about it | 13:28 |
| seb128 | doko, seems like one for TheMuso or diwic | 13:28 |
| seb128 | TheMuso, ^ could you have a look? | 13:29 |
| mpt | We could call them ... ramping and damping | 13:29 |
| mpt | Ramping is the weight increasing from 0 to 1 over the first 90 days | 13:29 |
| mpt | Damping is the weight declining from 1 to 0 over however long machines are known to usually take to do that | 13:29 |
| cjwatson | doko: Fixed for the next run; those two things were actually not unrelated, but two aspects of the same problem | 13:30 |
| doko | cjwatson, thanks! | 13:32 |
| doko | seb128, TheMuso: https://bugs.launchpad.net/ubuntu/+source/opus/+bug/1196967 | 13:34 |
| ubottu | Launchpad bug 1196967 in opus (Ubuntu) "[MIR] opus (b-d of jackd2)" [Undecided,Incomplete] | 13:34 |
| doko | jamespage, jarjar now requires libasm4-java instead of libasm3-java. should we just promote this, or trying to demote libasm3-java? | 13:36 |
| cjwatson | doko: Also fixed the slightly incorrect +filebug links for the next run | 13:36 |
| doko | cjwatson, I didn't note that one =) | 13:37 |
| cjwatson | quote_plus is my friend | 13:37 |
| jamespage | doko, we should go for demoting asm3 if possible - there are only two other deps in main | 13:38 |
| jamespage | * libcglib-java | 13:38 |
| jamespage | * libow-util-ant-tasks-java | 13:38 |
| doko | jamespage, ok, then I'll promote and file issues for these | 13:38 |
| doko | jamespage, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg now looks much nicer without the maven stuff | 13:39 |
| jamespage | doko, yeah - I had to drop the XSD support that ebourg added | 13:39 |
| jamespage | msv looks awkward - again I'll raise a bug to track we disabled it and why | 13:40 |
| jamespage | if someone wants to re-enable then converting msv to build with ant would make sense | 13:40 |
| doko | barry, there is a MIR missing for python-configparser for your python-configglue upload | 13:45 |
| barry | doko: ack | 13:50 |
| doko | barry, just uploaded configparser to remove the unused python-support b-d | 13:51 |
| mpt | ev, mistake fixed. https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=170&rev1=169 | 13:53 |
| jamespage | @pilot in | 13:53 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage | ||
| ev | mpt: right, that's how we have it in the code as well | 13:55 |
| doko | didrocks, seb128: who is handling qtwebkit-opensource-src? (b-d of signon-ui now) | 13:55 |
| didrocks | doko: Mirv | 13:56 |
| doko | Mirv, ^^^ | 13:57 |
| === oSoMoN_ is now known as oSoMoN | ||
| === wedgwood_away is now known as wedgwood | ||
| mpt | ev, basically the mistake was our April attempt to answer the question, What if the ramping and damping overlap? I thought the damping should immediately stop the ramping. But if they just multiply each other, the weighting curve is smoother over time, which suggests it's more correct. | 14:02 |
| === smartboyhw_ is now known as smartboyhw | ||
| doko | jamespage, https://bugs.launchpad.net/ubuntu/+source/ow-util-ant-tasks/+bug/1196979 | 14:07 |
| ubottu | Launchpad bug 1196979 in ow-util-ant-tasks (Ubuntu Saucy) "[MIR] libasm4-java (b-d of jarjar)" [Undecided,New] | 14:07 |
| ev | ah, right | 14:10 |
| jodh | stgraber/cjwatson: could you take a look at lp:~jamesodhunt/upstart/fix-libupstart and suggest why this might be failing at the 'make distcheck' stage due to lib/upstart/ not having been created? | 14:18 |
| doko | didrocks, hmm, and sphinxbase is ftbfs in -proposed | 14:38 |
| didrocks | doko: I think it's mterry who uploaded it, right? ^ | 14:39 |
| * mterry looks | 14:39 | |
| mterry | didrocks, hrm, so I am | 14:41 |
| xnox | jodh: in the gen target you use all pre-requisites via variable "$<", one of your prerequisites is "upstart" which is just a directory and actually shouldn't be part of the nih-dbus-tool call. And when using suffix rules the amount of targets $@ should match the amount of pre-requisites $<. | 14:41 |
| seb128 | didrocks, making mterry pay for enabling tests on build? :p | 14:42 |
| didrocks | seb128: exactly, failing on i386! :) | 14:42 |
| xnox | jodh: that might not be all of it, but it does result in out-of-order execution, where "upstart/com.ubuntu.Upstart.c" is generated from matching .xml pre-requisite, without considering "upstart" dependency. | 14:42 |
| mterry | didrocks, seb128: pfft, who uses i386 anymore? | 14:43 |
| didrocks | mterry: agreed, only some people like seb128 does that! :p | 14:43 |
| jodh | xnox: $< is the first prereq, $^ is all. | 14:43 |
| seb128 | mterry, you! | 14:43 |
| seb128 | mterry, (and me) | 14:43 |
| seb128 | or did you stop? | 14:43 |
| mterry | seb128, I'm on amd64 now | 14:44 |
| mterry | seb128, join us! | 14:44 |
| seb128 | bah | 14:44 |
| seb128 | mterry, I will when I get my new laptop | 14:44 |
| seb128 | mterry, I'm just pondering between 2 models, need to decide on that ;-) | 14:45 |
| xnox | jodh: excatly, which means that "upstart" prerequisite is not needed to build $@ using $< | 14:45 |
| xnox | thus not executed beforehand. | 14:45 |
| seb128 | mterry, I wish Dell was making an xps13 with a non glossy screen | 14:45 |
| dobey | i wish someone would make a 10" laptop that's at least 1080p, if not 4k2k | 14:46 |
| Sarvatt | seb128: absolute worst time to buy an ultrabook but x1 carbon has my recommendation from the current models (and its matte) :P | 14:53 |
| xnox | psivaa: i do wonder what has changed in the mean time, as well installer was not updated/uploaded in the timeframe between failures and the bug disappearing =) | 14:53 |
| cjwatson | I'm dealing with it :) | 14:54 |
| cjwatson | xnox: ^ | 14:54 |
| xnox | ack. | 14:55 |
| seb128 | Sarvatt, I hate thinkpads' look | 14:55 |
| jodh | xnox: I think it is. the problem seems to be that lib/upstart/ is getting created in the unpacked source directory, not _build/lib/upstart/ which is where I though it would create it as I've specified $(builddir). | 14:55 |
| doko | zul, apache2 failed to build | 14:55 |
| xnox | jodh: strange. | 14:56 |
| zul | doko: strange it built fine here | 14:56 |
| doko | zul using -proposed components? | 14:57 |
| zul | doko: no | 14:57 |
| zul | ill take a look | 14:58 |
| psivaa | xnox: is this about bug #1195690 | 15:05 |
| ubottu | bug 1195690 in ubiquity (Ubuntu) "Exception in GTK frontend during preseeded default installations" [High,New] https://launchpad.net/bugs/1195690 | 15:05 |
| psivaa | which does not occur anymore btw | 15:05 |
| cjwatson | Oh, OK, xnox may be asking psivaa about a different bug from the one I thought | 15:09 |
| cjwatson | Sorry for butting in, then :) | 15:09 |
| jdstrand | cjwatson: hi! we've defined the security section of the manifest file and have adjusted our tools to take a manifest file and look under the toplevel 'security' key for a JSON object (dictionary) | 15:10 |
| jdstrand | cjwatson: I read http://bazaar.launchpad.net/~click-hackers/click/trunk/view/head:/doc/file-format.rst, but it doesn't have a security section | 15:10 |
| xnox | psivaa: yeah that. | 15:11 |
| jdstrand | cjwatson: so, I was curious about your thoughts on that (I'd also like to submit a couple of tests for some manifests that have the security section in them) | 15:12 |
| psivaa | xnox: not sure how that got fixed, but does not occur anymore, i too did not see ubiquity changes during the weekend | 15:12 |
| jdstrand | cjwatson: in other news, we (sbeattie) should be working on the apparmor hook this week | 15:12 |
| jdstrand | cjwatson: I plan to write to ubuntu-devel soon for sdk coordination, but here is something of a preview - https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest | 15:15 |
| jdstrand | cjwatson: (note there is a click package section about half-way down) | 15:16 |
| cjwatson | jdstrand: I'm expecting you to fill in the section in that doc | 15:16 |
| cjwatson | I don't have any particular thoughts on it really | 15:16 |
| jdstrand | cjwatson: ah, when I read the manifest section, I thought you might have been thinking this should be x-security | 15:17 |
| cjwatson | Nope | 15:17 |
| cjwatson | x- is for local extensions, not for things we define for widespread use | 15:17 |
| cjwatson | the point being that that way we can define things without fear of clashing with somebody's local extension for whatever reason | 15:18 |
| jdstrand | cjwatson: ok cool. alright, so I'll do a merge request with the doc change and some tests. sbeattie will come along later and may ask about the click apparmor hook | 15:18 |
| cjwatson | cool, thanks | 15:18 |
| cjwatson | the hook interface may need to be changed; he shouldn't necessarily expect it to be adequate right now | 15:18 |
| jdstrand | sbeattie: ^ | 15:19 |
| jdstrand | cjwatson: ack. are we the first ones to do a hook? | 15:19 |
| cjwatson | yep | 15:20 |
| cjwatson | though I need to figure out one for desktop files / application upstart job integration / whatever it is | 15:20 |
| * jdstrand nods | 15:20 | |
| Daviey | Isn't X- as a prefix for an identifier considered deprecated now? | 15:20 |
| jamespage | cjwatson, there is a merge of efibootmgr in the sponsorship queue - https://code.launchpad.net/~logan/ubuntu/saucy/efibootmgr/0.5.4-6ubuntu1/+merge/169572 | 15:23 |
| jamespage | it looks OK - are you good for me to sponsor? | 15:23 |
| cjwatson | sure, though I thought I already said it was pointless :) | 15:23 |
| cjwatson | it's waiting for Sledge to accept a patch I sent to Debian and then it can be a sync | 15:24 |
| cjwatson | but whatever | 15:24 |
| jamespage | cjwatson, OKies | 15:24 |
| cjwatson | Daviey: who gets to deprecate prefixes on identifiers on a format I'm defining, if not me? | 15:24 |
| cjwatson | just curious | 15:25 |
| mdeslaur | hehe | 15:25 |
| Daviey | cjwatson: IETF covention, not a mandate . http://tools.ietf.org/html/rfc6648 | 15:26 |
| cjwatson | not sure what the IETF has to do with the price of bread here :) | 15:26 |
| Daviey | cjwatson: Just conversion, not saying you cannot. | 15:27 |
| cjwatson | I think file formats for packaging mechanisms designed to integrate with a particular product are a bit different from widespread interop protocols | 15:27 |
| Daviey | Sure. | 15:28 |
| cjwatson | I do understand the IETF's reasoning, and considered it - but I think at least at the moment the introduction of new fields is going to be rapid enough that I'd prefer to have an explicit local marker | 15:28 |
| Daviey | agreed. | 15:29 |
| cjwatson | maybe once things settle down a bit and we have a clearer registry for manifest key names it will be easier | 15:30 |
| cjwatson | for now I just wanted to keep local things out of the way and not have to worry about them | 15:30 |
| cjwatson | and sorry for being snippy, it's just a stressful project | 15:31 |
| === oSoMoN_ is now known as oSoMoN | ||
| === kk2 is now known as Kk2 | ||
| infinity | 3879 adconrad 20 0 872m 370m 12m R 100.9 2.3 63:42.74 unity-panel-ser | 16:00 |
| infinity | 7465 adconrad 20 0 3944m 3.4g 4548 R 95.6 21.6 19:00.93 indicator-sessi | 16:00 |
| infinity | ^-- I can't be the only one seeing this on a regular basis? | 16:00 |
| seb128 | infinity, it was fixed yesterday | 16:01 |
| seb128 | infinity, but I guess you didn't kill/restart the service since the update | 16:01 |
| infinity | seb128: Oh, shiny. I'll make with the upgrading. | 16:01 |
| seb128 | infinity, https://launchpad.net/ubuntu/+source/indicator-session/12.10.5daily13.06.19-0ubuntu2 | 16:01 |
| infinity | seb128: I hadn't upgraded at all since Friday or so. | 16:01 |
| seb128 | k | 16:02 |
| seb128 | upgrade, and kill indicator-session-service (it will respawn) | 16:02 |
| seb128 | things should be happier then | 16:02 |
| infinity | seb128: That'll make unity-panel-service stop being sad too, or is that a different bug? | 16:02 |
| seb128 | infinity, that seems like a different one but I'm unsure | 16:02 |
| infinity | Fun. | 16:03 |
| seb128 | kill the service as well | 16:03 |
| seb128 | see if it comes back | 16:03 |
| seb128 | if it does bug us | 16:03 |
| jdstrand | cjwatson: are the installation paths for click packages completely defined? ie, I know it is /opt and something with a reverse domain name, but I don't have the full path | 16:06 |
| cjwatson | jdstrand: I expect to have to fiddle with them to support image-based upgrade layouts | 16:07 |
| cjwatson | jdstrand: So, no, not set in stone yet | 16:07 |
| cjwatson | jdstrand: Currently it's /opt/click.ubuntu.com/<app-id>/<version or "current">/, but the prefix part of that may have to change | 16:08 |
| jdstrand | cjwatson: ok, thanks | 16:08 |
| ogra_ | Setting up lxc (0.9.0-0ubuntu16) ... | 16:20 |
| ogra_ | chfn: PAM: System error | 16:20 |
| ogra_ | adduser: `/usr/bin/chfn -f LXC dnsmasq lxc-dnsmasq' returned error code 1. Exiting. | 16:20 |
| ogra_ | dpkg: error processing lxc (--configure): | 16:20 |
| * ogra_ wonders if anyone has an idea how to work around this or if there is already some kind of standard reciepe | 16:21 | |
| ogra_ | (this is inside a chroot) | 16:21 |
| doko | cjwatson, thanks for libtool | 16:25 |
| cjwatson | you're welcome | 16:25 |
| xnox | doko: there are android specific binutils patches in linaro build. | 16:26 |
| xnox | doko: building those now. | 16:26 |
| ogra_ | oh | 16:30 |
| ogra_ | i wonder if the quoting is broken in lxc's postinst | 16:30 |
| ogra_ | hmm | 16:30 |
| ev | [17:33:19] <bdmurray> is it intended for the graph at https://errors.ubuntu.com/problem/27a5550c8a96660e9b19630655aa1c613772e29b to show the number of reports per day? | 16:38 |
| ev | [17:36:03] <bdmurray> The security team released a version of ubuntu-release-upgrader to security so I'm expecting to see less incidents per day but I don't know how to see if that is the case or not. | 16:38 |
| ev | (reposting here, so mpt can chime in if he so desires) | 16:38 |
| ev | so, I think that's the purpose of the version table. You can see if there are instances in the new version without there being noise from users who don't have the latest version installed. | 16:38 |
| mpt | ev, yep. I wonder if it would be worthwhile adding the release date of each version to the version table? | 16:40 |
| bdmurray | the version table doesn't tell how much more 89996 is than yesterday though | 16:41 |
| mpt | ev, bdmurray: If nearly all the reports for that error are in Ubuntu 12.10, why does 12.10 not show up in the graph? | 16:41 |
| mpt | The graph shows only Saucy, despite it having no errors in the table at all. | 16:41 |
| ev | mpt: if you think it wouldn't add to information overload, sure. Any suggestions to improve that page are definitely welcome. Right now I think it looks a mess. | 16:42 |
| ev | mpt: that's because the table back population job hasn't finished | 16:42 |
| jamespage | @pilot out | 16:42 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| mpt | ev, is that a job that lags for every bucket? | 16:42 |
| ev | mpt: no, it's accurate for new crashes | 16:43 |
| tedg | stgraber, Why do you have the dbus upstart job starting before the xsession one? | 16:43 |
| ev | just not ones before we added a new column family to track the relationship between releases, versions, and buckets | 16:43 |
| ev | (BucketVersions) | 16:43 |
| mpt | ok | 16:44 |
| * dholbach hugs jamespage | 16:45 | |
| jamespage | dholbach, managed to clear a few from the sponsoring list | 16:45 |
| jamespage | still lots of old ones left tho | 16:45 |
| mpt | ev, the left edge of every Y axis label is cropped, but I suspect that's not because there's too little room, but because it's showing error counts rather than rates | 16:46 |
| stgraber | tedg: because in the standard Xsession, dbus-agent is spawned before anything that's part of the session, that's to ensure we do the same thing, otherwise things like input methods would fail to connect | 16:46 |
| tedg | stgraber, Sure, but wouldn't that be before gnome-session, not the job that sets the env vars? | 16:47 |
| bdmurray | mpt: I want to be able to see if the error is occuring less now than it was. Where would I look for that information? | 16:47 |
| dholbach | jamespage, yeah, I noticed - I'll take a look tomorrow :) | 16:47 |
| ev | mpt: suggestions also welcome for dealing with very long stacktraces: https://errors.ubuntu.com/bucket/?id=/usr/sbin/NetworkManager:6:g_assertion_message:g_assertion_message_expr:handle_ip_config_timeout:real_act_stage4_ip6_config_timeout:nm_device_activate_ip6_config_timeout&format=json | 16:47 |
| ev | I played with using an expander there, but I wasn't particularly fond of it. Was thinking about trying something cute, like a CSS terminal window with scrolling, but maybe that's really silly? | 16:47 |
| ev | mpt: it's showing error rates, but yes, I've been working in spare moments today fixing the graphs | 16:48 |
| ev | possibly by moving from nvd3 to Rickshaw, since the former is somewhat dead upstream | 16:48 |
| stgraber | tedg: not sure I understand what you mean, anything that used to be part of the STARTUP command needs to be run after dbus is started, the only way of ensuring that this is done reliably with the env set for all the jobs is to do it before xsession-init can emit xsession | 16:49 |
| tedg | stgraber, So you're worried about the jobs that are start on xsession-init, not the xsession job itself. | 16:50 |
| ev | mpt: padding values also welcome :-P | 16:50 |
| tedg | stgraber, Shouldn't those jobs be start on started dbus and xsession-init SESSION=foo ? | 16:51 |
| mpt | ev, I don't see how the error rate for an individual error could be on the order of 100 times the error rate for all errors combined. | 16:51 |
| mpt | e.g. for 13.04 peaking in that particular error around 8.00, while the total error rate is around 0.08. | 16:51 |
| ev | I suspect that's due to the small population size for 13.04 when that was recorded | 16:52 |
| stgraber | tedg: so let's say you have a job that needs to set an environment variable for the user session and depends on dbus, how would you do that without race conditions if dbus was started after xsession-init is done? | 16:52 |
| ev | I was thinking about that last night. Tempted to filter out values if we have less than say, 100 machines | 16:52 |
| * ev pulls up the current algorithm for that graph | 16:52 | |
| mpt | ev, ah, so that will be fixed by the ramping anyway. | 16:52 |
| ev | good point | 16:53 |
| stgraber | tedg: all of the current conditions are designed so that all the user session environment is ready by the time xsession is emitted so that anything that starts after it inherits the full environment and we don't get into weird races | 16:53 |
| tedg | stgraber, That's specifically the issue I have :-) start on "started dbus and xsession-init SESSION=ubuntu" is what I want. | 16:53 |
| ev | so the graph is: number of instances for the bucket in the release / number of unique systems in a 90 period for the release | 16:54 |
| tedg | stgraber, The problem I have is that I want dbus to get that env var. | 16:54 |
| ev | the denominator is broken on production. It's using the number of unique systems in a 90 period for *all releases* | 16:54 |
| tedg | stgraber, Otherwise dbus activation doesn't get it. | 16:54 |
| ev | fixed on http://poppy-dev.local/ | 16:54 |
| stgraber | tedg: what env variable do you need dbus to get? | 16:54 |
| tedg | stgraber, I was looking at UNITY_MENUBAR_PROXY. | 16:54 |
| ev | mpt: but I do worry that the error rates are such low values | 16:55 |
| tedg | stgraber, It's not for dbus itself, but for things that get dbus activated | 16:55 |
| ev | http://poppy-dev.local/problem/88ac2e0e3a52787f78f23718c885431aba2a5f9c as one example | 16:55 |
| * cjwatson read denominator as dominator (publisher component) and panicked | 16:55 | |
| ev | (ignore the data in "what's unusual about this problem") | 16:55 |
| stgraber | tedg: and does that work if you turn off upstart user sessions? (it shouldn't) | 16:55 |
| tedg | stgraber, Right now it's being done by a script thrown in /etc, trying to "upstart-ize" it. | 16:56 |
| tedg | stgraber, So it builds the env before upstart runs today. | 16:56 |
| ev | cjwatson: have we moved on from naming machines after fruits and minerals to characters from adult cinema? | 16:57 |
| stgraber | tedg: just keep it that way then, there's nothing wrong with setting environment variables in /etc/X11/Xsession.d under upstart user sessions | 16:57 |
| tedg | ev, Quite clearly, we'll never run out of names with that scheme :-) | 16:57 |
| stgraber | tedg: the only case where you need to convert that stuff to user jobs is if you spawn a subprocess | 16:57 |
| ev | tedg: :D | 16:57 |
| tedg | stgraber, Well, and the fact that to remove it you have to use purge :-/ | 16:58 |
| tedg | stgraber, I imagine we'll (hopefully) not parse xsession.d for Unity 8 on Mir. | 16:59 |
| cjwatson | ev: you know about suggestions being dangerous sometimes, right? | 17:00 |
| ev | the Cassandra nodes are named after various demons. I wonder if this was foresight on elmo's part, knowing what would happen if we were allowed to throw massive amounts of data like heavy bricks at the webops team. | 17:00 |
| stgraber | tedg: probably not, though until then it's best not to break non-upstart sessions unless we really have to and in this case it doesn't sound like we do | 17:00 |
| ev | cjwatson: lol | 17:01 |
| mpt | bdmurray, if by "now" you mean "recent days", the graph would tell you that. If you mean "the current package version", the table would be a hint, but you couldn't tell whether it was low because the problem was fixed or just because no-one had updated. | 17:01 |
| tedg | stgraber, Well, it's kinda test case. And these env vars are only used in ubuntu sessions (upstart). | 17:01 |
| tedg | stgraber, So here we're not going to break anyone else. | 17:01 |
| bdmurray | mpt: I meant recent days so the graph sounds like a good place to look | 17:02 |
| mpt | Only three more weeks before the apparent Ubuntu 12.10 error rate climbs back above the apparent 12.04 rate :-] | 17:07 |
| xnox | mpt: Ubuntu Visionary and Fortune Teller | 17:08 |
| mpt | Okay, a bit more than three weeks. I predict July 27th. | 17:10 |
| barry | tedg: ping. was wondering what if any documentation is available on using dbus-test-runner, and if it's possible to use from python. i'm working on a new dbus service for the image based update client and i wanted to see if i could use d-t-r in my test suite | 17:30 |
| tedg | barry, Uhm, I've written a couple of blog posts. As far as the command line utility it should be usable anywhere. | 17:33 |
| tedg | barry, There's also a library, it should work with GObject Introspection, but I haven't tried. | 17:33 |
| tedg | barry, More out of not having a reason than and reason to believe it wouldn't work. | 17:33 |
| tedg | Figured someone would ask one day :-) | 17:34 |
| barry | tedg: today's the day! :) | 17:34 |
| tedg | Heh | 17:35 |
| barry | tedg: i think i found your blog. i'll take a look there. | 17:35 |
| tedg | barry, Are your tests using the glib mainloop? The lib needs that. | 17:35 |
| barry | tedg: right now i have no dbus support or tests. just gearing up for that now | 17:35 |
| tedg | barry, Okay, cool. I'd also recommend looking at the hud test suite. It does a good job of using dbusmock and dbustest to bring things together. | 17:36 |
| === halfie is now known as halfie|zzz | ||
| barry | tedg: this? http://bazaar.launchpad.net/~unity-team/unity/trunk/files/head:/tests/ | 17:37 |
| tedg | barry, No, here: http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.13.10/files/head:/tests/ | 17:38 |
| barry | tedg: cool, thanks | 17:38 |
| cjwatson | doko: Please could you merge libapache2-mod-perl2? Blocks several bits of the Apache 2.4 transition | 17:42 |
| doko | cjwatson, ok | 17:48 |
| Bayo | oi | 18:03 |
| Bayo | oi oi | 18:04 |
| sladen | Bayo: hello | 18:08 |
| zul | can an archive admin please review python-amqp please, openstack is kind of broken right now because of it | 18:26 |
| Daviey | zul: if nobody offers before hand, i will after i have eaten | 18:32 |
| zul | Daviey: cool thanks | 18:32 |
| infinity | tumbleweed: The logtail for https://launchpad.net/ubuntu/+source/pypy/2.0.2+dfsg-4/+build/4754026 hasn't moved in a day or so. Should I assume it's given up trying to do whatever happens next? | 18:37 |
| tumbleweed | infinity: the thing that comes next is a make | 18:39 |
| tumbleweed | well, once pyhon has shut down | 18:39 |
| tumbleweed | I've seen it stick there before on buildds, but never been able to investigate | 18:39 |
| infinity | Curious. I wonder what it's doing there. | 18:39 |
| tumbleweed | anyway, you are welcome to kill it if you're still expecting better ARM buildds soon | 18:42 |
| infinity | tumbleweed: We have them, but they're being tested currently. | 18:42 |
| infinity | tumbleweed: If being hung there isn't directly a result of having crap memory I/O, though, perhaps this is something worth debugging. | 18:43 |
| tumbleweed | I always assumed that when builds died here, it was because it took too long to get everything off swap during GCing all the objects in python shutdown | 18:43 |
| tumbleweed | s/died/timed out/ | 18:43 |
| infinity | tumbleweed: So, it's still doing... Something. | 18:45 |
| infinity | tumbleweed: http://paste.ubuntu.com/5838153/ | 18:45 |
| infinity | tumbleweed: Note the python in D state with a bazillion hours of CPU time. | 18:45 |
| tumbleweed | that's the translation. I guess it's blocking on that runsubprocess | 18:46 |
| tumbleweed | whatever that is doing... | 18:46 |
| infinity | Yeah, no idea. | 18:47 |
| infinity | I'm going to kill it and retry on a Calxeda node once they're in place. | 18:47 |
| infinity | And if that doesn't happen before we ship saucy, I'll remove the armhf binaries so it can all migrate for you. | 18:47 |
| * tumbleweed sees mentions of a pypy 2.1 branch in #pypy | 18:48 | |
| tumbleweed | infinity: thanks | 18:48 |
| === Nisstyre-laptop is now known as Nisstyre | ||
| === _ffio_ is now known as ffio | ||
| Daviey | zul: accepted, but i'd love to see a python3 package... | 19:05 |
| zul | Daviey: so would i | 19:05 |
| zul | Daviey: thanks | 19:05 |
| Daviey | zul: is there a py3 issue with it? | 19:15 |
| zul | Daviey: no i was more focused getting it on packaged | 19:16 |
| Daviey | zul: It will still need an MIR, right? | 19:16 |
| jtaylor | as you may be at new'ing can you have a look at pyparsing3? | 19:16 |
| zul | Daviey: correct | 19:16 |
| jtaylor | pytohn3-pyparsing | 19:16 |
| Daviey | jtaylor: Hmm, i'm not seeing it in the queue ? | 19:17 |
| jtaylor | hm, no idea | 19:18 |
| jtaylor | its in debian since more than a month | 19:18 |
| Daviey | jtaylor: hmm, it looks like you last touched it in ubuntu raring, and introduced a delta :) | 19:19 |
| jtaylor | yes but there is a new source now | 19:20 |
| Daviey | jtaylor: So we can just sync this? | 19:20 |
| jtaylor | doesn't it count as new? | 19:20 |
| Daviey | (sorry, you didn't introduce a delta) | 19:20 |
| jtaylor | autosync doesn'T pick it up | 19:20 |
| Daviey | jtaylor: Nah, you can just sync ontop | 19:20 |
| jtaylor | maybe because of the delta | 19:20 |
| Daviey | yep | 19:20 |
| Daviey | if there is ubuntu in the version string, it doesn't auto sync | 19:21 |
| jtaylor | python-pyparsing and python3-pyparsing are two different source packages | 19:21 |
| Daviey | Oh! | 19:21 |
| jtaylor | syncing pyparsing and new'ing python3-pyparsing should be done close together to not lose the py3 package for too long | 19:22 |
| Daviey | jtaylor: Okay, I've caught up now.. Thanks for outling it. :) | 19:27 |
| infinity | jtaylor: If the binary package name is the same, NEWing the new source first is the sane way to go. | 19:30 |
| jtaylor | I assumed that, thus I didn't sync yet :) | 19:30 |
| infinity | Let me look at that after I've upgraded my kernel and rebooted. :P | 19:31 |
| infinity | (I assume the new source is in the queue?) | 19:31 |
| Daviey | infinity: I just did it. | 19:31 |
| infinity | Oh. | 19:31 |
| infinity | Did you new it to a sane component (ie: wherever it was before)? | 19:31 |
| Daviey | I did indeed NEW it first, but perhaps i should have left a publisher run between it. | 19:31 |
| infinity | Ahh, it's in universe anyway. So, that's easy. | 19:32 |
| Daviey | infinity: i don't believe anything needs python3-parsing yet in main, so universe is fine | 19:33 |
| Daviey | ()the previous was also universe | 19:33 |
| jtaylor | binary packages can be split between two components? | 19:34 |
| infinity | jtaylor: Yep. | 19:34 |
| jtaylor | is that new? | 19:34 |
| infinity | No. | 19:34 |
| jtaylor | oh, right but build depends must all be main for main packages | 19:35 |
| * infinity actually accepts that sync. :P | 19:35 | |
| jtaylor | briefly though I split up fftw3 for nothing :) | 19:35 |
| infinity | jtaylor: Right, the source can't be split, so needs to be in the lowest-common-denominator component. | 19:35 |
| Daviey | It was planned to make it so some trivial build deps could remain in universe, but I believe that work was put on hold. | 19:36 |
| Daviey | Whilst we are on that topic... infinity - Would you be able to work on bug 888665 soon.. we could really do with that... | 19:37 |
| ubottu | bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Triaged] https://launchpad.net/bugs/888665 | 19:37 |
| infinity | Oh, did we finally come up with a critical use-case for that? | 19:37 |
| infinity | Is said critical use-case in the archive now? That'll make it easier to verify a fix. | 19:38 |
| Daviey | infinity: Yes juju-core preicse backports | 19:38 |
| Daviey | precse* | 19:38 |
| Daviey | BAH. | 19:38 |
| infinity | I suppose I can't get away with saying that not having those is a feature? :P | 19:38 |
| Laney | Pretty sure there's been something in mumble-backports waiting on that for a while | 19:39 |
| stgraber | couldn't it be worked around in nonvirt PPA + copy? | 19:39 |
| infinity | Laney: Good old something in some series somewhere. :) | 19:39 |
| stgraber | I thought we said that'd be the temporary workaround until we get LP fixed | 19:39 |
| Daviey | And jamespage also wanted to do some java jenkins stuff | 19:39 |
| Laney | infinity: I'm just saying that any new package doesn't make it more critical ;-) | 19:39 |
| infinity | stgraber: That's a perfectly reasonable workaround for Canonical folk, yeah. | 19:39 |
| Daviey | infinity: If it's not a ball breaker, i'd rather not use any bypasses. | 19:40 |
| infinity | Daviey: Am I to assume that backport juju-core and golang to precise is because you intend to actually recommend that combination to your users? | 19:41 |
| infinity | And do we then get to get into discussions of supportability, the insanity of static linking, etc? :P | 19:41 |
| infinity | (But yeah, I can look at 888665 soon) | 19:41 |
| Daviey | infinity: Yeah, Precise is very relevant to users of juju it seems.. and introducing whacking new features as SRU is bad mkay. | 19:41 |
| infinity | I think the initial "this isn't quite perfect, but would be an acceptable workaround" solution won't be much hassle to jam in. | 19:42 |
| Daviey | Yeah, that avoids blocking. | 19:42 |
| Laney | Ah, could be the one in the description that I'm thinking of | 19:42 |
| infinity | Daviey: Introducting new features as SRUs is bad, but if we're going to be semi-officially recommending people use those new features in parallel packages in a non-supported pocket, I'm not sure that's "better". | 19:42 |
| Laney | which is natty and so definitly super critical :) | 19:42 |
| infinity | Daviey: It's an end-run around policy that's in place specifically to protect users from what you're asking them to do. :P | 19:42 |
| Daviey | infinity: 'Supported' in this case is very much in the eye of the beholder. :) | 19:43 |
| infinity | jtaylor: Alright, new py3parsing source and binaries are in. | 19:44 |
| jtaylor | great thx | 19:44 |
| infinity | Daviey: I'm not sure I want to know what you mean by that. | 19:44 |
| infinity | Daviey: If you mean that Canonical, who has committed to 5yr support in the LTS, is dropping upstream support for one of its own projects, I might have to be a bit miffed by that. | 19:45 |
| Daviey | infinity: No, incorrect on 2 counts. | 19:46 |
| Daviey | One, juju is not in main for 12.04. | 19:46 |
| Daviey | Two, Supporting both is viable, and fixing bugs by SRU criteria for a universe package is also OK | 19:47 |
| infinity | Okay, not in main, fair. Though we push it pretty heavily as a pseudo-supported tech. | 19:47 |
| Laney | Sounds like it's more of a new series thing | 19:47 |
| Daviey | Which, unless i am mistaken, is what backports is precisely for? | 19:47 |
| infinity | I've always felt "it's not good enough for main, but it's good enough for us to widely advertise and encourage use" is a pretty sad cop-out to avoid having to live by the rules of main. | 19:47 |
| Daviey | Noted. | 19:48 |
| infinity | Daviey: Is there a fundamental reason why juju-core can't be made to work with go 1.0, while we're on the topic? | 20:00 |
| infinity | Daviey: backports has a policy of not allowing toolchain backports, but rather making the backported applications be modified to work with older toolchains. | 20:01 |
| infinity | Daviey: I realize that go has far fewer users in the archive than GCC, but I'm not sure that should buy it a pass. | 20:01 |
| TDO|Aquina | hy | 20:08 |
| slangasek | cjwatson: so I've finally gotten the gnu-efi problems from raring vis-a-vis shim sorted out, if only by virtue of pulling a new upstream version of gnu-efi | 20:08 |
| slangasek | which means I've also now uploaded shim 0.4 | 20:08 |
| slangasek | though before I send that off for signing, I think we should probably figure out what we're doing with MokManager and add that to the package | 20:09 |
| slangasek | and as the catalyst for this has been an OEM bug, I'm going to have to figure out what to do for 12.04.3... not sure that pulling all of gnu-efi + shim back is a sensible SRU, not sure trying to cherry-pick from shim is sensible either | 20:11 |
| slangasek | ah, fortunately shim FTBFS happily for me after upload even though it built fine here, so I guess I don't have to worry about *that* binary getting signed :P | 20:12 |
| Daviey | infinity: If anything else depended on this compiler, then there is a risk of an issue. I am not sure I have ever read this in policy, can you direct me to where that is? | 20:13 |
| Daviey | The version of the compiler is too basic in the one in stock precise AIUI. Doesn't have required features, but I can't speak authoritative about that. | 20:13 |
| infinity | Daviey: To be fair, I'm not seeing the "no toolchains" explicitly mentioned in the backport docs, rather than it being, perhaps, one of those "well, duh" things, as it would apply to, say, eglibc and GCC. | 20:15 |
| infinity | Daviey: It's true that very few things {build-,}dep on golang, which gives it a free pass in a lot of areas (backportability, static linking, etc), but it would be nice if we behaved AS IF it were widely-used and established sane policies around that. | 20:15 |
| Daviey | I don't see how they are the same thing.. | 20:15 |
| Daviey | I agree, but that is not the situation we are currently in | 20:16 |
| infinity | Daviey: You don't see how a compiler and standard library aren't the same as a compiler and standard library? | 20:16 |
| Daviey | No, i don't see how a compiler that has a 1:1 mapping with a package, and gcc are in the same category | 20:16 |
| infinity | Right, so you're taking the "no one uses Go, so it doesn't count as a toolchain package" argument. Like I said, I can see that, in the short term. | 20:17 |
| infinity | Long-term, it'll establish poor policy. | 20:17 |
| infinity | Assuming other people write things in Go some day. :P | 20:17 |
| Daviey | Naturally, it becomes more complex with increasing popularity | 20:17 |
| Daviey | Go is still a young language, and the compiler has made radical differences since the version in 12.04 | 20:18 |
| infinity | Sure. Intentionally targetting something to a newer language version *and* saying "oh, and we want this in precise" should have been a non-starter, but I understand you probably didn't have much say in that. | 20:19 |
| Sarvatt | why not name the package different, and SRU it instead if backports is a problem? kind of like mesa lts backports and llvm-3.x updates directly in precise-updates for it | 20:20 |
| infinity | Wouldn't be much different to someone writing something with shiny new C11/C++11 features and then demanding gcc-4.8 in precise. | 20:20 |
| Daviey | So, we have a choice.. deliver a poor experience, because it looks clean to you.. based on an undocumented made-upon-the-fly policy, or do the best thing for a vobrant project and it's users. Not to mention people wanting to have a packaged backport of an increasingly popular language | 20:20 |
| infinity | Sarvatt: Backports isn't inherently a problem, I can fix the bug, or we can build in a PPA. It's the principle of backporting toolchains that I'm arguing right now. | 20:21 |
| infinity | Sarvatt: And the llvm thing is a horrible compromise for the HWE stack but, yes, versioning the compiler could work in this case. | 20:22 |
| infinity | Wait a second. | 20:24 |
| infinity | "In order to backport juju-core we'll need go 1.1" | 20:24 |
| infinity | ^-- How can that be true, when we don't even have go 1.1 in raring or saucy? | 20:25 |
| infinity | (Yes, it's in saucy-proposed, but that means that juju-core demanded that dep only a month ago...) | 20:25 |
| infinity | If it needs 1.0.2, we could happily SRU that as a microrelease, if it's not completely insane. | 20:25 |
| * slangasek looks at the shim build failure. wtfbbq | 20:28 | |
| infinity | slangasek: That could do with a bit more verbosity... | 20:29 |
| slangasek | it rather could, couldn't it | 20:30 |
| slangasek | apparently 'openssl' is needed at build time | 20:30 |
| infinity | slangasek: You'll be happy(?) to know that it fails the same locally, at least. | 20:30 |
| slangasek | yeah, not sure how openssl got into my scratch chroot | 20:31 |
| infinity | slangasek: It used to be accidentally build-essential once upon a time, so you might have picked it up back then and never cleaned up. | 20:31 |
| slangasek | ah, could be | 20:32 |
| infinity | Someone should publish pitti's recipe for using sbuild backed by launchpad chroot tarballs. | 20:32 |
| infinity | Comes pretty close to foolproof for debugging. | 20:32 |
| Daviey | I'd like to see openssl in build-essential :) | 20:33 |
| slangasek | oh eew, something must've gone really wrong with a snapshot | 20:33 |
| slangasek | because cdbs is also in this chroot | 20:33 |
| infinity | slangasek: PURGE WITH FIRE. | 20:33 |
| infinity | slangasek: YOU CAN'T UNINSTALL EVIL. | 20:33 |
| slangasek | infinity: E: Command line option --with-fire is not understood | 20:34 |
| * infinity passes slangasek a lighter. | 20:34 | |
| slangasek | sudo apt-get purge --with-fire cdbs? | 20:34 |
| Daviey | infinity: I will circle back to the juju team and find out more detail on why they need a more recent toolchain. Note, that most of their development is happening in PPA's at the moment rather than saucy (they are working to fix this)... So.. don't work too much on dates. | 20:34 |
| jbicha | slangasek: always use -f | 20:34 |
| infinity | slangasek: http://www.penny-arcade.com/comic/1999/07/28 | 20:35 |
| slangasek | heh | 20:35 |
| infinity | slangasek: The date on that comic makes me feel old. That can't possibly have been 14 years ago. | 20:39 |
| slangasek | infinity: yeah, that was like, pre-php | 20:40 |
| slangasek | hardly seems possible | 20:40 |
| Laney | I was 13 | 20:40 |
| Laney | xnox was probably about to be born | 20:40 |
| slangasek | Laney: high-five for making infinity feel old | 20:40 |
| * infinity sobs quietly in the corner. | 20:40 | |
| Laney | :-) | 20:41 |
| * czajkowski hands infinity some cake | 20:48 | |
| xnox | Laney: that year my 10th birthday party was in McDonalds | 20:57 |
| adam_g | mterry, heya, is there anything i need to do to progress https://bugs.launchpad.net/ubuntu/+source/python-tidylib/+bug/1187185 ? | 21:33 |
| ubottu | Launchpad bug 1187185 in python-tidylib (Ubuntu) "[MIR] python-tidylib" [Undecided,Fix committed] | 21:33 |
| mterry | adam_g, feel free to have cheetah now depend on python-markdown, and an archive admin will promote as needed | 21:34 |
| mterry | adam_g, oh wait | 21:34 |
| mterry | adam_g, python-markdown itself isn't approved yet | 21:35 |
| mterry | adam_g, bug 1187191 | 21:35 |
| ubottu | bug 1187191 in python-markdown (Ubuntu) "[MIR] python-markdown" [Undecided,New] https://launchpad.net/bugs/1187191 | 21:35 |
| mterry | adam_g, waiting on a security review | 21:35 |
| adam_g | mterry, right. iw as gonna ping someone in security about that one | 21:35 |
| adam_g | thanks | 21:36 |
| mterry | adam_g, OK. Once all the MIRs are fix-committed, just have something pull them into main. Archive admins will see the mismatch (something wants to be in main and will promote if the paperwork checks out) | 21:36 |
| === salem_ is now known as _salem | ||
| tjaalton | is there a straightforward way for apt to use a usb stick as a source? | 21:41 |
| tjaalton | bah, I'll just reinstall the machine | 21:42 |
| tjaalton | no working networking hw on it which means no (easy) updates | 21:43 |
| sarnold | hrm, there used to be a "sneaker net" package for apt.. | 21:46 |
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
