| === mnepton is now known as mneptok | ||
| === mhall119 is now known as mhall119|fossetc | ||
| === happyaro1 is now known as happyaron | ||
| pitti | Good morning | 04:06 |
|---|---|---|
| pitti | yay, autopkgtest queues finally caught up over night | 04:07 |
| === NComman`` is now known as mcasadevall | ||
| === mcasadevall is now known as NCommander | ||
| bzoltan_ | zbenjamin: the reason for not using Conflicts was that it was forcing the users to manually upgrade the sdk packages. So a simple apt-get upgrade would hve kept back our packages. I have tried all options. Nothing worked. Apt seems to be too sensitive or our dependency tree is just too complex. | 06:05 |
| zbenjamin | bzoltan_: yeah, i think the guy is not here anymore :D | 06:06 |
| bzoltan_ | zbenjamin: I tried to address him, but yes he is offline | 06:06 |
| zbenjamin | bzoltan_: not even dist-upgrade worked? | 06:07 |
| bzoltan_ | zbenjamin: we need to simplify the package dependencies in the whole SDK | 06:07 |
| zbenjamin | (what you need for ppa upgrades anyway right) | 06:07 |
| bzoltan_ | zbenjamin: no ... dist and normal upgrade simple kept back the packages. | 06:07 |
| bzoltan_ | zbenjamin: but when apt-get install ubuntu-sdk-ide was used it went fine and it did remove the conflicting packages. No idea why it could not do it automatically | 06:08 |
| zbenjamin | bzoltan_: right i remember now :/ | 06:08 |
| FourDollars | pitti: Hi, could you help to review https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/278108 and https://code.launchpad.net/~fourdollars/ubuntu/trusty/gnome-desktop3/fix-lowest-brightness/+merge/278110? | 08:11 |
| dholbach | diwic, happy birthday! :) | 09:19 |
| diwic | dholbach, thanks! :-) | 09:19 |
| seb128 | oh, happy birthday diwic! | 09:20 |
| diwic | seb128, thanks! :-) | 09:20 |
| diwic | seb128, FYI, I went writing some code on that subwoofer bug, but not really happy with the result just yet. | 09:21 |
| seb128 | k, still quite some time before feature freeze anyway ;-) | 09:21 |
| Mirv | hi friendly core-dev again, to workaround train not understanding trunk translation updates in https://requests.ci-train.ubuntu.com/#/ticket/621 , please do ./copy-package --from=~ci-train-ppa-service/ubuntu/landing-060 --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed -b unity-api - everything else is already copied | 09:36 |
| seb128 | Mirv, what do you mean by "train not understanding trunk translation updates"? | 09:39 |
| Mirv | seb128: the ticket claims unity8 has unbuilt changes, because translation updates land to trunk automatically https://code.launchpad.net/~unity-team/unity8/trunk | 09:39 |
| Mirv | train just got a feature that detects trunk changes, unfortunately it doesn't understand translation updates are alright | 09:40 |
| Mirv | and the publish can't be forced | 09:40 |
| seb128 | don't you have a checkbox to overwrite those errors? | 09:40 |
| Mirv | no, there's no force for the publish job | 09:40 |
| seb128 | k | 09:40 |
| seb128 | but why are some copied then? | 09:40 |
| Mirv | seb128: because they're in universe and I'm MOTU | 09:41 |
| seb128 | I see | 09:41 |
| seb128 | thanks for the details | 09:41 |
| seb128 | Mirv, copied for you | 09:41 |
| Mirv | seb128: thanks, and mzanetti thanks you too! | 09:41 |
| seb128 | yw! | 09:41 |
| seb128 | infinity, new selinux seems to make glibc autopkgtests grumpy, http://autopkgtest.ubuntu.com/packages/g/glibc/xenial/amd64/ seems like we need to backport https://sourceware.org/git/?p=glibc.git;a=commit;h=808696696837b8b8fc858f2e6f8d4e40e26e1308 | 09:50 |
| seb128 | pitti, dbus ones being unhappy are what you pinged Laney about earlier right? | 09:50 |
| pitti | seb128: yes | 09:51 |
| infinity | seb128: We'll get that for free with 2.22, but I might have to pull it in earlier if 2.22 and I keep fighting. | 09:51 |
| seb128 | infinity, ok, I was just pointing it because it's blocking selinux which is blocking some other things | 09:51 |
| seb128 | but anyway needs to sort out dbus as well, so it's probably not going to be today | 09:52 |
| pitti | do we urgently need libselinux in xenial? | 09:52 |
| pitti | seb128: oh, is that a library transition? | 09:52 |
| seb128 | pitti, no, but there are a bunch of things batched with it | 09:53 |
| seb128 | I was just looking at excuses | 09:53 |
| pitti | ah right | 09:53 |
| pitti | yofel: FYI: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/k/kdelibs4support/20151119_133155@/log.gz -- the same version worked before, is that acc failure due to a dependency change? | 09:54 |
| pitti | yofel: this was the run for kio | 09:55 |
| infinity | If glibc 2.22 and I don't agree soon, I need to do an opload for a 1-liner for s390x anyway, so I can grab that fix too. | 09:55 |
| pitti | yofel: kdelibs4support/amd64 works fine against other -proposed packages, so kio does sound related | 09:55 |
| pitti | infinity: uploading glibc on a Friday afternoon, what could possibly go wrong :) | 09:55 |
| infinity | pitti: No meaningful code changes. But yes, it would explode your infra something nasty. :P | 09:56 |
| infinity | pitti: Until we're building s390x in LP, though, I don't care, I can hand-edit my 1-liner for my bootstrap stuff. :P | 09:57 |
| infinity | pitti: (It's a Breaks against a binNMU version of something only on s390x, derp) | 09:57 |
| === marcustomlinson is now known as marcustomlinson| | ||
| === marcustomlinson| is now known as marcustomlinson | ||
| didrocks | bdmurray: slangasek: hey, do you mind subscribing foundations-bugs to https://bugs.launchpad.net/ubuntu/+source/ptyprocess? That will enable me to promote it to main. It's a new dep of pexpect (process handling part has been externalized in 4.0) for which foundation is already the bug subscriber | 10:44 |
| === _salem is now known as salem_ | ||
| infinity | didrocks: Done. | 11:10 |
| pitti | infinity, Laney: please remove http://autopkgtest.ubuntu.com/running.html from your browsers/brains and use http://autopkgtest.ubuntu.com/running.shtml from now on | 11:20 |
| pitti | (link in the menu is updated, of course) | 11:20 |
| pitti | apw too ^ | 11:21 |
| * mgedmin mutters "apache rewrite rules" under his breath | 11:21 | |
| pitti | using SSI to include the dynamic bit is a bit icky; I tried for about 45 mins to use JS for that, but failed | 11:21 |
| pitti | including that on the client side, possibly with auto-refresh would be great | 11:22 |
| pitti | but I'm a web/JS n00b; if someone knows how to do that, please talk to me :) | 11:22 |
| mgedmin | I once made apache process SSI directives in .html files: http://paste.ubuntu.com/13363773/ | 11:26 |
| infinity | pitti: You give my brain too much credit. | 11:31 |
| pitti | infinity: the entirety of what I know about internet addresses is contained in my firefox' awesome bar cache :) | 11:39 |
| infinity | pitti: Yeah, ditto, though in that case, I follow the link from the front page. | 11:39 |
| infinity | pitti: That said, if you want to fix firefox's brain, a 301 will make it rewrite the cache. | 11:40 |
| infinity | (If you have enough control to 301) | 11:40 |
| pitti | mgedmin: I know, but the .shtml page is autogenerated, so it's prone to get lost | 11:41 |
| cjwatson | pitti: The crontab change to build xenial langpack exports on Sunday is live now, so you can set your end of it up to run on Mondays. | 11:44 |
| pitti | cjwatson: cool, thanks! I need to run the first one by hand, so I'll do that next Monday and then set the crontab | 11:45 |
| * pitti adds it commented out for now | 11:45 | |
| yofel | pitti: probably a dependency change, at least I didn't change anything explicitely - except I did the acc change wrong. I'll have time to look at this in the evening (and at all the arm64 FTBFS) | 11:46 |
| pitti | yofel: I retried teh arm64 FTBFS, seem happy now | 11:47 |
| pitti | was a weird temp issue with installing the b-deps | 11:47 |
| pitti | yofel: the test seems to work in general, as it does succeed when running against other packages, just not against kio | 11:47 |
| yofel | oh ok, I got a couple mails earlier, but if that's solved great. Thanks | 11:47 |
| yofel | ok, I'll look into that | 11:48 |
| pitti | yofel: ah, the new ones you got from this morning are real | 11:48 |
| pitti | like https://launchpadlibrarian.net/227091984/buildlog_ubuntu-xenial-arm64.kio_5.15.0-0ubuntu3_BUILDING.txt.gz | 11:48 |
| pitti | uninstallable b-deps again, looks like some ongoing transition again | 11:49 |
| yofel | dangit ^^. Ok, I'll check if it's something kde-internal anyway. | 11:50 |
| pitti | at least it's now a "real" error, not this weird "refusing to remove b-deps" one | 11:50 |
| VsyachePuz | does ubuntu-panel support panel applets, similar to DBus-based panel applets of gnome and mate? | 12:22 |
| cpaelzer | pitti, is adt-buildvm-ubuntu-cloud supposed to work with "-r xenial" already? | 12:29 |
| seb128 | VsyachePuz, there is no ubuntu-panel | 12:41 |
| seb128 | if you mean the unity panel, it doesn't support "applets"/isn't compatible with the gnome-panel ones no, but it has indicators | 12:41 |
| cpaelzer | pitti, when I try adt-buildvm-ubuntu-clou with xenial - I get this http://paste.ubuntu.com/13364697/ (seems to pass cloud init, but then hangs) | 12:49 |
| cpaelzer | pitti, I lack an example of one that works to compare | 12:49 |
| cpaelzer | fyi my system where this is running is trusty - if that might be a reason | 12:50 |
| coreycb | pitti, do we list the current MRE packages anywhere? they used to be listed on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions | 12:54 |
| === enrico_ is now known as enrico | ||
| VsyachePuz | seb128: so, may i say, that ("Application Indicators" === "Panel Applets") and ("System Indicators" === "System Tray Icon") ? | 12:59 |
| seb128 | the other way around rather | 13:00 |
| seb128 | system indicators are things like the sound control or the session menu | 13:01 |
| seb128 | so the equivalent to applets | 13:01 |
| sladen | Windicators!!! | 13:03 |
| VsyachePuz | seb128: I want to implement "minimize to progressbar" feature | 13:04 |
| seb128 | what is a progressbar? | 13:05 |
| VsyachePuz | seb128: and that progressbar should be long (i.e. 200 pixels long, not 22x22pt as an icon) | 13:05 |
| VsyachePuz | seb128: https://en.wikipedia.org/wiki/Progress_bar | 13:06 |
| seb128 | yeah, I know what that widget is | 13:06 |
| seb128 | but "minimizing to a progress bar" is not a concept I grasp I think | 13:06 |
| VsyachePuz | seb128: I have an application which have an UI for making queries, and performs long frocessing for each query | 13:07 |
| VsyachePuz | I want to minimize it, but track the completion of operations | 13:07 |
| VsyachePuz | the concept is "minimize to tray", but I used it as an analogy | 13:08 |
| seb128 | well, use an appindicator | 13:08 |
| VsyachePuz | i don't want small icon, i want long widget | 13:09 |
| VsyachePuz | may be even several of them | 13:10 |
| VsyachePuz | one for each query | 13:10 |
| seb128 | that's not possible | 13:12 |
| seb128 | you can have the status/summary in the indicator menu though | 13:13 |
| === dpm is now known as dpm-afk | ||
| VsyachePuz | seb128: "that's not possible" - I am not sure. This is possible on MATE, and in Unity Menu is Indicator (long indicator). So long indicators should be possible | 13:17 |
| seb128 | VsyachePuz, indicators can only contain a label or an icon in the panel | 13:18 |
| seb128 | no custom rendering or other widgets | 13:18 |
| pitti | cpaelzer: the host system shouldn't matter that much; but I highly recommend using a current autopkgtest version | 13:26 |
| pitti | cpaelzer: I think I remember having to add some hacks for newer cloud-inits; so if that's indeed trusty's autopkgtest, please try with a recent one | 13:28 |
| pitti | coreycb: they are gone, we generalized the SRU policy instead | 13:28 |
| pitti | coreycb: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html | 13:28 |
| coreycb | pitti, ok thanks | 13:28 |
| VsyachePuz | seb128: what is "icon"? Can it be nonsquare? Can it be 200x22px ? | 13:35 |
| mterry | seb128, thanks for the gdal rdep rebuilds | 13:36 |
| cpaelzer | pitti, yeah seems so on my wily system it just worked | 13:38 |
| cpaelzer | pitti, I'll try updating to a more recent autopkgtest on my Trusty and try again | 13:38 |
| cpaelzer | pitti, just FYI here would be the full log that worked http://paste.ubuntu.com/13365391/ | 13:40 |
| cpaelzer | and the difference starts at some cloud-init things, so yes it could be just as you suggested | 13:40 |
| cpaelzer | I'll let you know later if it worked | 13:40 |
| pitti | stgraber: hm, that i386 lxcfs failure seems fairly resistant against retries: http://autopkgtest.ubuntu.com/packages/l/lxcfs/xenial/i386/ | 13:53 |
| seb128 | mterry, yw | 13:55 |
| seb128 | VsyachePuz, I don't know, I guess you can try | 13:55 |
| mterry | kenvandine, poke about that deja-dup branch | 13:56 |
| doko | xnox, are you going to address the cmake merge? | 13:58 |
| xnox | doko, well, i win the TIL... | 13:58 |
| infinity | xnox: You do now, anyway. :P | 14:00 |
| infinity | doko: Shame about your versioning breaking the merge a bit, though. | 14:00 |
| xnox | doko, i believe steve tricked me into doing that, via infinity. | 14:00 |
| infinity | xnox: Oh, I guess you could work around the version issue by merging from experimental, if you're feeling bold. | 14:01 |
| infinity | (Might want to test in a devirt PPA first...) | 14:01 |
| kenvandine | mterry, sorry... i will look at it today! | 14:04 |
| mterry | kenvandine, no worries :) | 14:05 |
| cyphermox | good morning! | 14:06 |
| kenvandine | mterry, actually this MR isn't nearly as big as i thought... i don't need to worry about the vapi :) | 14:06 |
| mterry | kenvandine, but that's where I hid all my bugs! | 14:07 |
| kenvandine | :) | 14:08 |
| nemo | Say, anyone here use VPNs and might have a little sympathy for the rather-broken-yet-easyish-to-fix-once-figured-out behaviour of opensc and vmware-view ? | 14:13 |
| nemo | https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770 I documented the fix I ended up doing, here. | 14:13 |
| ubottu | Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed] | 14:13 |
| kenvandine | mterry, to test this, i just need to uninstall duplicity right? | 14:15 |
| kenvandine | and run deja-dupe, which should prompt to install it? | 14:15 |
| mterry | kenvandine, yeah should do | 14:15 |
| mterry | kenvandine, specifically, run either of the preferences interfaces (running deja-dup from command line will just give an error) | 14:15 |
| VsyachePuz | seb128: look at this article - http://www.omgubuntu.co.uk/2010/11/omg-5-five-ways-to-switch-between-workspaces-in-ubuntu there is a workspace switcher, which is long indicator - http://www.omgubuntu.co.uk/wp-content/uploads/2010/11/Selection_0021.png | 14:25 |
| seb128 | VsyachePuz, if you say so | 14:25 |
| seb128 | VsyachePuz, to me it looks like an icon with a menu | 14:25 |
| seb128 | it's 3. | 14:25 |
| VsyachePuz | seb128: ok, i am wrong. first looks like gnome workspace switcher | 14:27 |
| nemo | VsyachePuz: and the MATE one | 14:30 |
| nemo | gnome2 that is | 14:30 |
| nemo | I have it on my monitor just in front of me | 14:30 |
| nemo | my fav 'cause it has window shape, and icon for fullscreened windows | 14:30 |
| nemo | and, well, 'cause MATE | 14:31 |
| === dpm-afk is now known as dpm | ||
| VsyachePuz | nemo: yes, I set wanda fish to 0 frames, and panel height to 64 pixels. Receive long image without problem. | 14:41 |
| nemo | VsyachePuz: ah. to each their own. me, I set the panel even smaller, to free up more vertical space on the monitor. I'm using 24px height | 14:42 |
| nemo | and only one bar | 14:43 |
| VsyachePuz | There is also WingPanel from Elementary OS, it allows widgets and AppIndicators, but didn't find specs | 14:44 |
| didrocks | VsyachePuz: there is clearly a way to achieve something like that with indicators (I guess generating multiple images and pushing them one after another). Look at workrave, they have some progress bar in their unity indicator | 14:45 |
| Mirv | hello. the big Bluez 5 landing (biggest part to vivid overlay, but also some to xenial) needs a core dev for one of the three silos: https://ci-train.ubuntu.com/job/ubuntu-landing-043-2-publish/15/ - packaging_changes there, run a job when ok with it | 14:59 |
| VsyachePuz | didrocks: it have a class for each type of panel... - https://github.com/rcaelers/workrave/blob/branch_v1_10/frontend/applets/indicator/src/indicator-workrave.c | 14:59 |
| Mirv | ticket with QA Granted approval at https://requests.ci-train.ubuntu.com/#/ticket/242 | 14:59 |
| didrocks | VsyachePuz: indeed | 14:59 |
| Mirv | morphis is your point of contact regarding the silo itself | 15:00 |
| cpaelzer | pitti, I can confirm after updating autopkgtest to 3.18.1 it works on my trusty system - thanks | 15:05 |
| pitti | cpaelzer: great | 15:05 |
| VsyachePuz | didrocks: there https://github.com/rcaelers/workrave/tree/branch_v1_10/frontend/applets is "cinnamon", "common", "gnome-shell", "gnome2", "gnome3", "indicator", "mate", "Win32", "xfce". Are you it's author? | 15:05 |
| davmor2 | cyphermox, seb128, pitti: is that silo something you could help with at all please ^^^ | 15:06 |
| didrocks | VsyachePuz: not at all, just pointing something that I saw that could help you | 15:06 |
| kenvandine | mterry, i'm also seeing an error trying to install | 15:06 |
| kenvandine | The version 0.7.01-1ubuntu1/Ubuntu of duplicity isn't available. | 15:06 |
| VsyachePuz | didrocks:seb128: thanks | 15:07 |
| didrocks | yw | 15:07 |
| kenvandine | mterry, oh... i think i know why | 15:08 |
| mterry | hm | 15:08 |
| kenvandine | mterry, apt currently isn't happen with keys on my desktop :) | 15:14 |
| kenvandine | i bet that's causing packagekit to barf | 15:14 |
| mterry | kenvandine, keys? | 15:14 |
| kenvandine | apt spews GPG errors right now | 15:15 |
| mterry | oh ah | 15:15 |
| kenvandine | i need to sort that out, just haven't had time | 15:15 |
| kenvandine | mterry, i'm more concerned with the test failures, ideas? | 15:15 |
| mterry | kenvandine, test failures? Oh, I hadn't noticed. Let me run tests again | 15:16 |
| kenvandine | in package build http://paste.ubuntu.com/13365813/ | 15:16 |
| mterry | kenvandine, say what | 15:16 |
| mterry | weird | 15:16 |
| * mterry will try to reproduce, maybe that's only in a chroot | 15:17 | |
| kenvandine | mterry, i fixed the gpg issues in apt and it's still failing to install | 15:21 |
| kenvandine | same error message | 15:21 |
| xnox | Laney, we have webhooks now, right? can transition tracker update itself everytime there is a push to the config branch? | 15:22 |
| kenvandine | mterry, could it be a missing depends? i don't have packagekit installed :) | 15:22 |
| mterry | kenvandine, I think you just need libpackagekit | 15:22 |
| mterry | kenvandine, it talks to aptdaemon | 15:22 |
| kenvandine | ah | 15:23 |
| mterry | kenvandine, nothing in this branch is working for you! :) | 15:23 |
| kenvandine | so not it | 15:23 |
| kenvandine | nope :/ | 15:23 |
| morphis | cyphermox, seb128, pitti: anyone having time to help merging that silo? | 15:24 |
| seb128 | morphis, "that silo"? | 15:24 |
| seb128 | I lack context | 15:24 |
| cyphermox | morphis: looking... | 15:24 |
| seb128 | k, seems cyphermox is on it ;-) | 15:24 |
| morphis | <Mirv> hello. the big Bluez 5 landing (biggest part to vivid overlay, but also some to xenial) needs a core dev for one of the three silos: https://ci-train.ubuntu.com/job/ubuntu-landing-043-2-publish/15/ - packaging_changes there, run a job when ok with it | 15:24 |
| morphis | <Mirv> ticket with QA Granted approval at https://requests.ci-train.ubuntu.com/#/ticket/242 | 15:24 |
| morphis | cyphermox: thanks! | 15:24 |
| morphis | awe: ^^ | 15:24 |
| seb128 | oh, that's landing, great! | 15:24 |
| morphis | seb128: yes, finally :) | 15:25 |
| cyphermox | hum, wat | 15:25 |
| awe | w00t! | 15:26 |
| awe | seb128, looks like we have a fix for qt dbus too | 15:27 |
| seb128 | awe, this week is a good one :-) | 15:27 |
| seb128 | and way to wrap it | 15:27 |
| morphis | seb128: one of the next steps is to sync the landings of bluez on desktop and Touch | 15:29 |
| cyphermox | morphis: is indicator-bluetooth just a port to bluez5? that's not so obvious from the changelog | 15:29 |
| morphis | cyphermox: it is and just and merge with what is in wily/xenial | 15:30 |
| morphis | no further changes | 15:30 |
| seb128 | morphis, right | 15:30 |
| cyphermox | I wasn't aware that we could permit this kind of very obvious deviation from SRU/backport rules for a stable release | 15:32 |
| awe | huh? | 15:33 |
| Mirv | cyphermox: overlay is treated differently vs features from actual Ubuntu releases | 15:33 |
| awe | isn't this a landing to the PPA? | 15:33 |
| cyphermox | Mirv: sure but I was under the impression that we were still asking that things that got in the overlay also got in SRUs | 15:33 |
| awe | um, no | 15:34 |
| awe | not for bluez5 | 15:34 |
| awe | that would be super risky | 15:34 |
| infinity | cyphermox: The overlay is pretty Wild West. Sadly. | 15:34 |
| awe | if folks want bluez5 on the desktop, they upgrade to wily | 15:34 |
| infinity | cyphermox: Its entire raison d'etre is to circumvent SRU policy. :P | 15:34 |
| awe | this isn't a case of wild-west | 15:34 |
| awe | we landed bluez5 in wily | 15:34 |
| awe | and are backported to just touch | 15:35 |
| awe | as it's a huge change | 15:35 |
| awe | and requires lots of QA | 15:35 |
| awe | it'd be way too risky to SRU | 15:35 |
| awe | and AFAIK, nobody is asking us to | 15:35 |
| infinity | awe: It's a battle I lost long ago, but I think "it's too risky to SRU" also means "it's too risky to push in an OTA". | 15:36 |
| cyphermox | infinity: well, most things that happen in the overlay should still not just happen in the overlay, but backporting bluez is special | 15:36 |
| awe | desktop can be installed on an order of magnitude more devices than a touch release | 15:36 |
| awe | not a fair comparison at all | 15:36 |
| morphis | cyphermox, awe: there is some worked needed to get the same experience in a Touch image produced from xenial but that is a different story and will be worked on next | 15:36 |
| awe | morphis, indeed | 15:40 |
| cyphermox | morphis: so why does bluez have +15.04.20151023? just because silo, or is that frankensteined or a git cherry-pick? | 15:41 |
| morphis | cyphermox: it's landing through the citrain | 15:41 |
| morphis | and the origin for this is a MP | 15:41 |
| cyphermox | ok, that's what I thought | 15:41 |
| cyphermox | morphis: please make sure to upload all the extra patches you're adding to xenial, too, unless they'd be for some reason phone-only | 15:43 |
| cyphermox | (and upstream as appropriate) | 15:44 |
| morphis | cyphermox: that is the plan | 15:44 |
| morphis | I really want to align bluez uploads for current devel and phone | 15:44 |
| morphis | so that we upload the same to both together | 15:44 |
| morphis | but that is one of the next steps | 15:45 |
| caribou | I'm preparing a new kdump-tool package which require a change in its config file (/etc/default/kdump-tools) | 15:45 |
| caribou | what should the maintainer script do : display a warning ? | 15:45 |
| caribou | I also need to add a prompt to enable it by default | 15:45 |
| caribou | what is the appropriate way to address such a situation ? | 15:46 |
| mterry | kenvandine, ok, added missing build-dep to let deja-dup build in a pbuilder (whoops), and all tests pass there, as well as locally | 15:46 |
| mterry | kenvandine, how are you running it? | 15:46 |
| rbasak | caribou: was /etc/default/kdump-tools being shipped as a conffile previously? | 15:46 |
| caribou | rbasak: yes | 15:46 |
| rbasak | caribou: then you can just update it, and dpkg will take care of the prompt. Unless you want to avoid the prompt somehow. | 15:46 |
| mterry | kenvandine, ahem, accidentally pushed to trunk, will fix that | 15:47 |
| rbasak | caribou: ah, but adding a prompt to change the file based on the answer is trickier. | 15:47 |
| kenvandine | mterry, i just did a 'bzr bd' | 15:47 |
| cyphermox | morphis: same applies to pulse, I think we should have HSP support patches there too, and upstreamed, etc. | 15:47 |
| caribou | rbasak: yes, I understand that I will have the standard one, but is it expected to be sufficient ? if the user select the default which is to keep the old one, it may cause problems | 15:47 |
| caribou | rbasak: two config variable that were not used previously are expected to be enabled now | 15:48 |
| caribou | (i.e. they come with the new conffile) | 15:48 |
| morphis | cyphermox: yes, but as already said, that is the next step | 15:49 |
| rbasak | If the user blindly picks to keep the old conffile then there will always be problems IMHO. | 15:49 |
| morphis | cyphermox: take this for all changes in silo 43 | 15:49 |
| rbasak | So I wouldn't be too worried about that case. | 15:49 |
| kenvandine | mterry, any ideas why it's failing to install? | 15:49 |
| rbasak | If you can detect it then you could warn the user through debconf in the postinst I suppose, if it's really important. | 15:49 |
| caribou | rbasak: ok, just wanted to be sure that showing a warning was not required | 15:49 |
| mterry | kenvandine, no, that also worked for me last time I tried it | 15:49 |
| kenvandine | mterry: The version 0.7.01-1ubuntu1/Ubuntu of duplicity isn't available. | 15:50 |
| kenvandine | that version string looks odd, with the /Ubuntu in it | 15:50 |
| cyphermox | morphis: yes, but I'm pointing it out because it's important, just ask here for a sponsor when you have an upload ready for xenial. | 15:50 |
| caribou | rbasak: well, in wily & xenial, kernel crash dump will fail if they're not enabled :-/ | 15:50 |
| kenvandine | but i don't think your code is involved in that | 15:50 |
| mterry | kenvandine, it's also an old version | 15:50 |
| kenvandine | mterry, i'm on vivid + stable overlay | 15:50 |
| rbasak | caribou: I'm not sure what others would say but I'd say that no warning is required if all you're doing is updating a conffile. Providing it's really a conffile as seen by dpkg. | 15:50 |
| mterry | kenvandine, what release are you on? | 15:50 |
| mterry | kenvandine, ah hrm | 15:50 |
| morphis | cyphermox: yes | 15:50 |
| mterry | kenvandine, why? ;) | 15:50 |
| rbasak | caribou: however, if you want to prompt to change the file, that's tricker, because your maintainer script can't just go and modify the conffile. | 15:50 |
| rbasak | Since if it does dpkg will think the user modified it. | 15:51 |
| kenvandine | mterry, that's what i'm developing for right now :) | 15:51 |
| mterry | and xenial! | 15:51 |
| kenvandine | i'll switch soonish :) | 15:51 |
| kenvandine | mterry, do you think that's why it's failing? | 15:51 |
| mterry | kenvandine, looks like tests work for me in bzr bd too (just sanity checking) | 15:51 |
| mterry | kenvandine, probably not? | 15:51 |
| mterry | imma try again on my machine to install | 15:52 |
| morphis | cyphermox: btw. does anything speaks against releasing bluez through citrain with MP to xenial as well? | 15:52 |
| kenvandine | mterry, i already have libpackagekit-glib2-dev | 15:52 |
| mterry | kenvandine, yeah, if you didn't, it wouldn't even build | 15:52 |
| cyphermox | morphis: not really, aside from that it shouldn't be an MP, it should be a direct upload | 15:52 |
| cyphermox | that way we don't have outlanding version numbers | 15:52 |
| morphis | which makes a coordinated review process pretty hard | 15:53 |
| cyphermox | ie. we should be more or less in line with the debian packaging if possible, and not have special versions | 15:53 |
| cyphermox | no | 15:53 |
| kenvandine | mterry, could the test failures have anything to do with me being on vivid? | 15:53 |
| caribou | rbasak: my guess is that if the user doesn't bring in the new config file which is part of the fix, then he shouldn't be surprized if it doesn't work | 15:53 |
| cyphermox | it's the same review in silos | 15:53 |
| mterry | kenvandine, I also doubt that | 15:53 |
| kenvandine | i wouldn't think so | 15:53 |
| morphis | cyphermox: so where do I do my review then? there is no real instance I can put my comments in | 15:53 |
| cyphermox | morphis: do it in a bug | 15:54 |
| cyphermox | if you want to do things in a MP, you're free to keep stuff there | 15:54 |
| cyphermox | but the upload through the silo shouldn't be via a MP | 15:54 |
| mterry | kenvandine, ok install worked for me (w/ deja-dup-preferences, but "unity-control-center deja-dup" crashes for me!) | 15:54 |
| mterry | kenvandine, so I'm going to look at that crash | 15:55 |
| cyphermox | should work just the same as NM, basically. you have a packaging branch, just it's not relevant to the silos | 15:55 |
| mterry | kenvandine, and I can't explain either of the failures you see | 15:55 |
| kenvandine | i'm building in sbuild now | 15:55 |
| rbasak | caribou: agreed | 15:55 |
| rbasak | caribou: that part is fine. | 15:55 |
| cyphermox | that is, unless there's a way to use the MPs anyway but not having version number mangling because of it | 15:55 |
| mterry | kenvandine, what does "apt-cache policy duplicity" say? | 15:55 |
| caribou | rbasak: ok, thanks! | 15:55 |
| rbasak | caribou: but if you want to display a prompt on install and ask the user about a default, then you can't just modify the conffile to store the result. | 15:55 |
| kenvandine | Installed: (none) | 15:55 |
| kenvandine | Candidate: 0.7.01-1ubuntu1 | 15:55 |
| rbasak | caribou: because then the user will get an unexpected dpkg prompt on a future upgrade. | 15:56 |
| morphis | cyphermox: so where can I comment then directly on the source which is landing in the bug? | 15:56 |
| cyphermox | morphis: I don't know what you mean by that | 15:56 |
| caribou | rbasak: the conffile will come with the default, so choosing the default will not modify the conffile | 15:56 |
| rbasak | caribou: what if the user chooses the non-default? | 15:56 |
| caribou | rbasak: then we would want him to confirm that he changed the default behavior on the next upgrade, right ? | 15:57 |
| cyphermox | merge proposals don't *have* to be used with a silo landing, they're not linked to it. You're free to prepare a merge in a separate branch for a new package upload and file a merge request against the real packaging branch | 15:57 |
| caribou | rbasak: default being kernel crash dump is enabled | 15:57 |
| rbasak | caribou: no, then the next upgrade should remember what the user asked for and make it continue to happen without prompting. | 15:58 |
| rbasak | caribou: there is a distinction here between users modifying conffiles themselves directly (in which case we expect them to know what they're doing and handle a conffile prompt by themselves) and choosing an option in a menu (in which case a conffile prompt isn't acceptable). | 15:58 |
| caribou | rbasak: ok, then the script will check if a previous value exist (I suppose that it is the expected way to do) | 15:59 |
| cyphermox | morphis: the problem with silo version numbering is that in the case of non-Canonical projects, it's confusing: it essentially means you're taking a snapshot of a source code repository at a specific point in time, which is false for bluez -- we're taking a release tarball, and adding patches on top via quilt or whatnot. | 15:59 |
| rbasak | caribou: there are a few different ways of approaching this. ucf might be appropriate here. | 15:59 |
| caribou | rbasak: that's the first time I do one from scratch, I'll fetch a few example in other packages | 15:59 |
| mvo | infinity: took a bit longer (wanted to get to it at the start of the week already) but https://launchpad.net/~mvo/+archive/ubuntu/apt-xenial/+packages is coming together, I guess early next week we can land the new apt 1.2^W2.0 in xenial | 16:00 |
| caribou | mvo: what can be longer than infinitty ? | 16:00 |
| mvo | caribou: lol | 16:00 |
| infinity | mvo: 2.0, you say? | 16:01 |
| morphis | cyphermox: basically I prefer the way of handing things of to automatic process and only say yes or no to what needs to land. With this I have to merge the MP, build a source package myself and upload it (through someone else) to the silo | 16:01 |
| infinity | mvo: I guess it does have a lot of new shiny, but after a decade of 0.x, jumping to 2 is very chrome/firefox of you. :P | 16:01 |
| caribou | rbasak: if you don't mind, I'll show you what I got working before I upload. You should be back by then | 16:01 |
| morphis | where in the last two steps through the manual process something can be added to the package which I didn't reviewed | 16:01 |
| rbasak | caribou: sure | 16:03 |
| cyphermox | morphis: what? | 16:03 |
| cjwatson | mvo: FYI I've been doing some very preliminary work on by-hash support in LP, but I want to get xz indexes landed first | 16:03 |
| cyphermox | morphis: whatever the method used is, bluez should certainly *not* have a version number of 5.35+32095 in the archive, because it's completely incorrect and misleading | 16:04 |
| awe | cyphermox, it's something I've pointed out in the past as well | 16:04 |
| awe | cyphermox, I thought this was about a landing to the PPA? | 16:04 |
| cjwatson | mvo: which is going to involve some internal shuffling, because I think the right approach for that is to enable xz only for >= xenial (and disable bz2 once things are working well) | 16:04 |
| rbasak | xz indexes would be really nice. Thank you for working on it! | 16:04 |
| morphis | awe: it is | 16:04 |
| cyphermox | awe: notice I said in the archive, and I let your silo through already | 16:05 |
| awe | cyphermox, thanks | 16:05 |
| cyphermox | which, in retrospect, was wrong because now it's be always higher than anything unless we upload 5.36 | 16:05 |
| infinity | Yeah, that shouldn't be in the overlay either. | 16:05 |
| morphis | cyphermox: thanks! | 16:06 |
| infinity | If it was copied to the overlay, please get someone to delete it and re-upload with a sane version. | 16:06 |
| cyphermox | oh, but we do have 5.36 in xenial | 16:06 |
| infinity | Or, I guess, if xenial is already higher, whatever. | 16:06 |
| cyphermox | infinity: I'm tempted to not care for this case because xenial is already higher, yeah | 16:06 |
| infinity | But distro packages with a proper orig shouldn't be re-packed with strange versions for silos. | 16:06 |
| mvo | cjwatson: nice! will by-hash use apt-ftparchive? if so I might need to put some more work into it, I'm not sure how well the current approaches scale in there (i.e. if it can handle this size of an archive without getting too slow) | 16:07 |
| morphis | cyphermox, infinity: why don't we modify citrain then to do proper version numbers for those packages? | 16:07 |
| mvo | infinity: 1.2 vs 2.0 is a bit of an internal joke :P its probably going to be 1.2 its pretty nice and shinney but maybe not 2.0 shinny | 16:07 |
| awe | morphis, +1 | 16:08 |
| cyphermox | morphis: by all means. | 16:08 |
| cyphermox | robru: sil2100: ^ | 16:08 |
| morphis | there are multiple things: | 16:08 |
| morphis | having a MP gives us a review protocol with all things documented | 16:08 |
| morphis | all back and forth | 16:09 |
| morphis | using an MP in citrain and a silo ensures that we only land what is in the MP and nobody has the chance to include anything else | 16:09 |
| morphis | which isn't reviewed by others | 16:09 |
| cyphermox | nobody would include anything else when doing a direct upload to the PPA | 16:09 |
| awe | morphis, yes... you're correct, and there's been much back and forth over this issue for as long as I've worked on touch | 16:09 |
| awe | cyphermox, but they *could* | 16:10 |
| cyphermox | those who have access to do it are expected to know better, unless they have a very good reason | 16:10 |
| morphis | exactly | 16:10 |
| cyphermox | meh | 16:10 |
| awe | people can make mistakes | 16:10 |
| awe | it's a valid point | 16:10 |
| morphis | if we have the automatic to do such things why don't we use them? | 16:10 |
| awe | morphis, we do | 16:11 |
| awe | primarily for packages developed by Canonical | 16:11 |
| awe | it gets trickier when we're talking about packages that we mostly maintain | 16:11 |
| morphis | but I don't see any reason not to use them (optional) for other components too if the maintainer / developer wants to | 16:12 |
| morphis | my primary reason for bluez is that we have to coordinate now between different kinds of users | 16:12 |
| morphis | Desktop, touch, IoT | 16:12 |
| morphis | which brings in a bunch of different use cases and we have to ensure nothing breaks any of those use cases | 16:13 |
| awe | morphis, sure... except there are some problems when doing so. One being the version mangling | 16:13 |
| infinity | And what's the MP against? It's not against the archive. | 16:14 |
| infinity | Which is authoritative. | 16:14 |
| infinity | So "the MP makes sure no unwanted changes get in" is false. | 16:14 |
| morphis | against the packaging branch | 16:14 |
| awe | how do you propose a MP against a tarball?? | 16:14 |
| awe | if there is one | 16:14 |
| cyphermox | infinity: morphis has a pretty good packaging branch | 16:15 |
| infinity | I don't propose an MP against a tarball. | 16:15 |
| infinity | Cause the tarball shouldn't change. :P | 16:15 |
| infinity | Except, it is changing. | 16:15 |
| cyphermox | morphis: the point is people could upload and not notice there was a packaging branch | 16:15 |
| cjwatson | mvo: We need to have a way to put things into the by-hash arrangement for PPAs too, so we might as well just do that bit of it ourselves - so we'd still be using apt-ftparchive, but then moving the results around afterwards | 16:15 |
| infinity | Which is wrong. | 16:15 |
| morphis | infinity: IMHO all changes should go into the packaging branch first even if the archive is the authoritative | 16:15 |
| cyphermox | or upload not going through the silo, because any core dev is free to upload any package | 16:15 |
| cjwatson | rbasak: Is your interest just for size reasons? | 16:15 |
| awe | morphis, not all packages have packaging branches | 16:16 |
| infinity | morphis: That's a lovely opinion, but factually incorrect for anything I can upload to the archive. | 16:16 |
| awe | eg. qtbase | 16:16 |
| infinity | morphis: Sorry to burst your bubble with reality. | 16:16 |
| awe | come on guys | 16:16 |
| awe | can we please re-focus | 16:16 |
| morphis | awe: I don't mean everything in the archive needs to take this approach | 16:16 |
| awe | on what needs to happen for bluez5? | 16:16 |
| cjwatson | rbasak: (it's a little smaller, but not lots smaller) | 16:16 |
| awe | and save this discussion for later? | 16:16 |
| morphis | however for a single component I need to maintain across different use cases it makes life a lot easier | 16:16 |
| cyphermox | awe: simple, either upload directly to the silo, and/or fix the versioning in citrain. | 16:17 |
| awe | no argument | 16:17 |
| awe | cyphermox, there are three silos | 16:17 |
| awe | one for ofono dual landing | 16:17 |
| awe | AFAIK, that's OK | 16:17 |
| awe | then we have a silo for indicator, et al that's dual-landing | 16:17 |
| cyphermox | any bluez upload in a silo should be a direct upload until the train knows not to touch the version number in that case | 16:17 |
| awe | the final silo for bluez5 is just PPA | 16:17 |
| awe | so are you asking us to fix the second silo? | 16:18 |
| infinity | cjwatson: Assuming apt is picking a sane dictionary size, xz is probably also faster to decompress than bz2, which is a nice win. | 16:18 |
| awe | cyphermox, so the issue is that the version number of the bluez silo for ppa upload only is wrong? | 16:18 |
| cyphermox | and tbh, it could be as simple as looking at .bzr-builddeb/default.conf for a specific option, depending on what morphis uses in the packaging branch | 16:18 |
| infinity | cjwatson: bz2 is so terribad that I tend to force gz all over the place and take the bandwidth hit instead. :P | 16:18 |
| cyphermox | awe: I suppose. I have only looked at one silo | 16:18 |
| awe | so which silo are you objecting to? # please? | 16:19 |
| cyphermox | I was objecting to the verion that was in silo 43 | 16:19 |
| cyphermox | I let it through, but it was wrong | 16:19 |
| dupingping | I am proud that I became a Ubuntu member. | 16:19 |
| * awe looks | 16:19 | |
| cyphermox | except it's not the biggest deal for this case because it's still lower than what is in xenial | 16:20 |
| morphis | cyphermox: so there is no TODO left for us to land bluez5 for right now? | 16:20 |
| cyphermox | are you trying to do other bluez landings? | 16:20 |
| morphis | not yet | 16:20 |
| cjwatson | infinity: I think it just uses xz's default, i.e. -6 | 16:20 |
| cjwatson | which is an 8MiB dictionary size | 16:21 |
| morphis | cyphermox: but I would like to ugprade to .36 | 16:21 |
| morphis | cyphermox: so lets do it like this: | 16:21 |
| morphis | we take what we have right now | 16:21 |
| infinity | cjwatson: Yeah, I think -6 is generally faster than bz2 for decompression (much worse for compression, but who cares). | 16:21 |
| morphis | we have to do some bug fixes anyway for bluez during the ota9 cycle | 16:21 |
| morphis | and I would like to get 5.36 into ota9 as well | 16:21 |
| cjwatson | infinity: I care a little, but it's probably dominated by other things | 16:21 |
| morphis | as it includes bug fixes we should better have | 16:21 |
| cjwatson | Will find out a bit later | 16:21 |
| morphis | cyphermox: so my next landing will not use a MP but a manually uploaded package which fixes the version number, ok? | 16:22 |
| cyphermox | if you want to get to 5.36 in the overlay, just merge whatever we have in xenial with what is currently in the overlay, and then direct upload to the silo you'll do your landing with | 16:22 |
| cyphermox | you can still use a packaging branch, the only thing that won't be a MP will be what the train uses to land | 16:22 |
| rbasak | cjwatson: decompression speed reasons. | 16:22 |
| cyphermox | you're still free to use MPs to prepare the work | 16:22 |
| morphis | cyphermox: agreed | 16:23 |
| awe | cyphermox, unless we get a fix for CI by then | 16:23 |
| cyphermox | awe: sure | 16:23 |
| awe | we should be able to special case this | 16:23 |
| rbasak | cjwatson: bz2 decompression often seems to be the reason that apt holds things up. I don't have numbers but I believe xz decompression is significantly faster. | 16:23 |
| awe | if we can't get a more generic fix | 16:23 |
| stgraber | hallyn: can you look at the lxcfs test failure? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/l/lxcfs/20151120_091728@/log.gz | 16:24 |
| stgraber | hallyn: doesn't seem to be racy or if it is, well, it's mostly failing | 16:24 |
| cjwatson | infinity: So, it'll certainly slow down the publisher some. Unscientific: http://paste.ubuntu.com/13367748/ (those are apt's default settings) | 16:25 |
| infinity | cjwatson: Given the nature of Packages/Sources/Translation (ascii and/or utf-8, only one or two languages, highly repetetive), one could probably experiment with even smaller dictionaries than the default, but I'm not sure it's worth it. | 16:25 |
| cjwatson | infinity: Dictionary size also determines memory requirements for decompression | 16:27 |
| infinity | cjwatson: Indeed, I'm quite familiar with the handy table in the manpage. :) | 16:27 |
| cjwatson | infinity: http://paste.ubuntu.com/13367838/ | 16:28 |
| rbasak | So when is apt going to automatically drop back to gz when the dictionary in the xz is too big? :) | 16:28 |
| cjwatson | corresponding Packages.bz2 is 6971349 bytes, Packages.gz is 8998549 bytes | 16:29 |
| rbasak | Big leap seems to be at -4 from a quick glance | 16:30 |
| hallyn | stgraber: i386, bet it's a 32/64bit error in the recentmeminfo code i merged | 16:30 |
| cjwatson | decompression (on pepo) of default settings for Packages.bz2 is ~1.3s, Packages.xz ~0.65s | 16:30 |
| infinity | cjwatson: Yeah, that's kinda leading me to believe -6 is just fine, so long as the publisher doesn't have a massive sad about it. | 16:31 |
| cjwatson | decompressing xz -4 is about the same, maybe a few centiseconds slower | 16:31 |
| infinity | We don't support anything where the memory pressure from decompressing -6 should be a problem. | 16:31 |
| stgraber | hallyn: that's an amd64 failure, different and probably caused by the change of uptime layout: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxcfs/20151120_051440@/log.gz | 16:31 |
| cjwatson | infinity: suggests to me that it will add about two minutes to publisher runtime for a release pocket | 16:32 |
| hallyn | stgraber: uh, i chnaged that testcase to handle that. wtf | 16:32 |
| infinity | cjwatson: Drop ls-lR, and you come out even. :P | 16:32 |
| cjwatson | infinity: xz -4 would be more like a minute or less I think | 16:33 |
| infinity | cjwatson: Yeah, I like -4 on the publisher side, but I like it less on the client side, at least from those numbers. | 16:33 |
| kenvandine | mterry, i get the same failures in sbuild | 16:33 |
| mterry | kenvandine, you're a monster | 16:34 |
| cjwatson | infinity: It's a little less compelling, true | 16:34 |
| infinity | cjwatson: I suppose benchmarking decompression on something craptastic like a Panda (or a Fast Model!) would perhaps also help. | 16:34 |
| kenvandine | mterry, :-p | 16:34 |
| kenvandine | mterry, vivid chroot though | 16:34 |
| cjwatson | infinity: do you have one handy? | 16:34 |
| kenvandine | mterry, i'll try with xenial | 16:34 |
| infinity | cjwatson: I do indeed. | 16:34 |
| mterry | kenvandine, I don't know why it would be different, but worth a shot | 16:34 |
| hallyn | stgraber: the amd64 testcases id efinately ran locally... | 16:35 |
| cjwatson | infinity: (anyway, ls-lR is in finalize, so it's not on the critical path for e.g. proposed-migration kicking off) | 16:35 |
| stgraber | hallyn: well, it does pass, sometimes: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxcfs/20151120_014250@/log.gz | 16:35 |
| cjwatson | I'm more concerned by timings before the dists switch. | 16:36 |
| hallyn | stgraber: oh, but wiat, that amd64 failure, args are opposite of what i expected. the test isn't wrong, for some reason lxcfs really did spit out ints instead of floats. | 16:38 |
| hallyn | all righ ti'll figure it out | 16:38 |
| infinity | cjwatson: Well, I can tell you that Pandas sure suck at compressing things. :P | 16:40 |
| infinity | cjwatson: When that's done, I'll decompress a bit for you. | 16:40 |
| hallyn | stgraber: those two runs are installing different versions of lxcfs before running the tests | 16:43 |
| hallyn | looks like a testrunner eror to me | 16:43 |
| infinity | cjwatson: http://paste.ubuntu.com/13368221/ | 16:44 |
| infinity | cjwatson: So -6 looks reproducibly faster client-side (I assume not true once you swap but, again, we shouldn't support anything with that sort of memory pressure). | 16:44 |
| infinity | cjwatson: Anything xz is such a massive win over bzip2 though, that it's really about how much bandwidth win we're getting over gzip. | 16:45 |
| hallyn | stgraber: indeed that older version spit out integers | 16:45 |
| cjwatson | infinity: Right. Not a huge amount of difference over -4, so perhaps we can start out with -6 and then drop to -4 if the publisher slowdown is too difficult. | 16:47 |
| hallyn | pitti: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxcfs/20151120_051440@/log.gz | 16:48 |
| hallyn | pitti: ^ that one is building the xenial-proposed package, but it installs the xenial package, then runs the xenial-proposed tests against xenial pkg (which fails, correctly) | 16:48 |
| dupingping | hi, popey_ | 16:56 |
| dupingping | how are you today? | 16:56 |
| dupingping | I sent an email to sabdfl | 16:56 |
| === popey_ is now known as popey | ||
| popey | ok | 16:57 |
| dupingping | at the email, I asked about the time when the cert mail arrived here. | 16:58 |
| dupingping | popey: Mark will be very busy, right? | 16:59 |
| popey | I did say be patient | 16:59 |
| popey | You seem to not be doing that | 16:59 |
| dupingping | yes, I'm just waiting. | 17:00 |
| popey | pinging mark isn't waiting, but anyway, you choice | 17:00 |
| hallyn | stgraber: well this i386 lxcfs crash is not at all what i expected. seems to be a glibc bug in realloc. | 17:01 |
| infinity | hallyn: You have a pointer? | 17:02 |
| dupingping | popey: yes, I'll wait. | 17:02 |
| * infinity waits for "no, that's the problem." | 17:02 | |
| hallyn | infinity: not sure what you mean by a pointer - http://paste.ubuntu.com/13368646/ is the gdb stracktrace | 17:02 |
| infinity | hallyn: I meant a pointer to the bug, rather than a pointer to memory. ;) | 17:03 |
| hallyn | oh. no open bug i know of but it's https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/l/lxcfs/20151120_091728@/log.gz | 17:03 |
| * davmor2 points at infinity "no, you're the problem" close enough right? | 17:03 | |
| * hallyn back in a few, sigh | 17:03 | |
| hallyn | wonder if a little c prog can reproduce this | 17:05 |
| dupingping | popey: i got a reply from him. | 17:05 |
| dupingping | very kind | 17:05 |
| popey | Good stuff | 17:05 |
| pitti | hallyn: ah, thanks for pointing that out; indeed, I'll look into that on Monday | 17:05 |
| dupingping | So I'll wait. | 17:05 |
| * pitti waves | 17:06 | |
| hallyn | pitti: thx | 17:08 |
| hallyn | oh, actually this may be a bit urgent - it means lxcfs on xenial has unfixed cves until that clears | 17:09 |
| infinity | hallyn: We don't promise security support in the devel series, it's not terribly urgent. | 17:10 |
| hallyn | ok | 17:12 |
| hallyn | so i can't reproduce this standalone so i must be messing something up in the context | 17:12 |
| infinity | hallyn: I kinda want to blame fuse, but I haven't looked closely. | 17:14 |
| hallyn | infinity: it's possible another thread is to blame i suppose | 17:16 |
| hallyn | fwiw http://paste.ubuntu.com/13368976/ shows the relevant values, everything looks sane | 17:16 |
| hallyn | maybe if i thread my testcase | 17:17 |
| infinity | hallyn: I'm hip-deep in punchcards, but if no one's got a better idea by EOD Monday, give me a jab. | 17:17 |
| hallyn | you're supposed to swim in *money* not punchards | 17:18 |
| hallyn | thx, will do | 17:18 |
| infinity | hallyn: Yeah, I didn't read the fine print. | 17:18 |
| rmblrd21 | would ubuntu-devel be the right place to report that ubuntu updates break ath10k support everytime an update is coming in? | 17:37 |
| rmblrd21 | kernel update of course | 17:37 |
| rmblrd21 | sry, mean firmware file update | 17:37 |
| dobey | a bug report on the ath10k package would be the right place i would think | 17:41 |
| rmblrd21 | ok | 17:41 |
| hallyn | shoulda looked higher in the scrollback earlier - http://paste.ubuntu.com/13369752/ | 17:43 |
| hallyn | i guess glibc is putting its foot down. | 17:46 |
| hallyn | stgraber: ok so i do think this is a glibc bug, but i'm going to post a workaround for lxcfs for now | 18:13 |
| hallyn | (glibc is throwing an assertion, i think, bc i'm reallocing to a size which isn't big enough compared to the prev size. shouldn't do that) | 18:14 |
| kenvandine | mterry, same failures in a xenial build (sbuild) | 18:26 |
| mterry | kenvandine, guh | 18:28 |
| kenvandine | sorry, i'm an evil monster :) | 18:28 |
| kenvandine | mterry, in case it's useful, http://paste.ubuntu.com/13370636/ | 18:31 |
| mterry | kenvandine, a bunch of "Failed with an unknown error"... :( | 18:32 |
| kenvandine | yeah, doesn't seem useful | 18:33 |
| hallyn | stgraber: proposed fix: https://github.com/lxc/lxcfs/pull/54 but i'm now going to rebuild glibc with some debugging to see the root cause | 18:39 |
| mterry | barry, just to give you an update on the duplicity side of the python3-only effort, I have a branch ready to let deja-dup install duplicity on-demand. But it's apparently not working in all cases. Working on it slowly | 18:42 |
| attente | hi, where is the file /etc/environment coming from? | 18:46 |
| attente | what project would i have to checkout to add a line to it? | 18:48 |
| infinity | attente: It's written by various installers at install time. What line did you want to add, and why? | 19:00 |
| attente | infinity: GTK_IM_MODULE=Maliit, which will be needed eventually (not yet) to get gtk apps communicating with the osk. but only on the phone, not on the desktop | 19:02 |
| infinity | attente: That almost certainly belongs in some sort of graphical session startup, not in /etc/environment. | 19:04 |
| attente | infinity: so should the line for QT_IM_MODULE=maliitphablet be moved elsewhere? | 19:04 |
| infinity | attente: If that's in /etc/environment on the phone today, yeah, that should probably be elsewhere too. :P | 19:05 |
| attente | infinity: heh, ok. any ideas for where would be good? i'll move the QT one too | 19:06 |
| infinity | attente: But if it is, and you're just looking to double-up on the same hack, it looks like it lives in livecd-rootfs//livecd-rootfs/live-build/ubuntu-touch/hooks/48-setup-env.chroot | 19:07 |
| infinity | attente: I have no strong opinions about where it *should* be, but I suspect someone in #ubuntu-desktop could point you at how graphical sessions are meant to be set up. | 19:07 |
| infinity | attente: For now, though, the path of least resistance would be to pile on top of the existing livecd-rootfs hack, it seems. | 19:08 |
| attente | infinity: ok, great, thanks. i won't add it since i don't need it quite yet, but it's good to know just in case | 19:08 |
| barry | mterry: ok, thanks for the update | 19:32 |
| tdaitx | infinity, I just grabber a xenial schroot and its sources.list file is set to wily | 20:03 |
| infinity | tdaitx: Yup. It's a wily chroot, lp-buildd overrides sources.list. | 20:03 |
| tdaitx | http://launchpadlibrarian.net/222053869/chroot-ubuntu-xenial-amd64.tar.bz2 | 20:03 |
| infinity | tdaitx: I should probably freshen them soon. | 20:03 |
| tdaitx | infinity, oh, sbuild-launchpad-chroot does not override that | 20:04 |
| infinity | tdaitx: No, indeed, I think cyphermox had a patch to fix that. | 20:04 |
| cyphermox | err, it's in xenial already | 20:04 |
| infinity | tdaitx: There you go. Grab xenial's version. | 20:05 |
| cyphermox | tdaitx: you want sbuild-launchpad-chroot 0.13 yeah | 20:05 |
| tdaitx | yeah that explains, I'm using a wily distro, | 20:05 |
| tdaitx | cyphermox, thanks =) | 20:05 |
| tdaitx | infinity, thank you o> | 20:07 |
| infinity | RAOF: Hey, you know how long ago, Debian X tried really hard (and very successfully) to make X completely scorched-earth bootstrappable by splitting out x11proto-* and lib* and such, and carefully avoiding circular deps? | 20:09 |
| infinity | RAOF: That's totally broken in Ubuntu now with mesa and mir interdepending. :P | 20:09 |
| infinity | RAOF: (Easy loop to break, but annoying) | 20:09 |
| mterry | kenvandine, testing the branch on my other wily laptop, everything passes and I was able to install duplicity | 20:16 |
| tdaitx | infinity, heh, my first run in with circular dependencies in packages was as a gentoo user long ago, trying to build gnome... iirc there was a particular way to go, otherwise it ended up in a circular dependency hell | 20:16 |
| mterry | kenvandine, I don't get why we are seeing two very different results | 20:16 |
| mterry | kenvandine, I also fixed the crasher I was seeing | 20:16 |
| infinity | tdaitx: I'm quite practised at this. ;) | 20:16 |
| kenvandine | mterry, dunno... no idea what could be different | 20:17 |
| mterry | you tested in a clean xenial environment and got the error. I don't get why I wouldn't see it in my clean environments | 20:20 |
| mterry | kenvandine, is there anything that sbuild takes from your environment/HOME? ... does trunk give the same errors for you? | 20:22 |
| kenvandine | mterry, freshly created xenial sbuild schroot | 20:23 |
| kenvandine | not sure | 20:23 |
| kenvandine | i can try trunk too | 20:23 |
| mterry | kenvandine, sorry man for the trouble | 20:24 |
| kenvandine | no worries | 20:24 |
| kenvandine | mterry, trunk has the same failures in sbuild with xenial | 20:35 |
| === waspinator is now known as Guest57243 | ||
| mterry | kenvandine, ok. so at least no regression... and I doubt the usefulness of those failures, since deja-dup has built in LP in September | 20:36 |
| mterry | with no changes in trunk | 20:36 |
| mterry | well... some changes in trunk | 20:38 |
| mterry | but nothing I would expect would cause that (removed some unused code) | 20:38 |
| kenvandine | mterry, building it on my vivid laptop now | 20:39 |
| kenvandine | mterry, also trying under a fresh user account as well | 20:42 |
| kenvandine | mterry, same failures on my vivid desktop when built under a new user account, so that rules out env from my home | 20:44 |
| mterry | kenvandine, gar! | 20:45 |
| kenvandine | mterry, still building on my laptop... xenial with sbuild | 20:45 |
| * mterry is trying to think | 20:45 | |
| mterry | so something in my account? | 20:45 |
| mterry | maybe I'll try a fresh user | 20:45 |
| mterry | But LP doesn't mind it... | 20:45 |
| kenvandine | maybe it would now | 20:46 |
| kenvandine | tests starting on my laptop :) | 20:46 |
| kenvandine | 53% tests passed, 45 tests failed out of 95 | 20:46 |
| kenvandine | same thing on my laptop :/ | 20:46 |
| kenvandine | mterry, so your box has the secret sauce :) | 20:48 |
| mterry | kenvandine, fresh account on my wily box built fine | 21:05 |
| mterry | kenvandine, am trying in LP as a tie-breaker build :) | 21:05 |
| kenvandine | mterry, :/ | 21:05 |
| smoser | infinity, https://bugs.launchpad.net/ubuntu/+source/linux-lts-wily/+bug/1511497 can you make netboot-wily exist in places like http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/ ? | 21:14 |
| ubottu | Launchpad bug 1511497 in maas-images "No hwe-w kernel for 14.04" [Medium,Confirmed] | 21:14 |
| infinity | smoser: That's the plan. | 21:17 |
| infinity | smoser: It's a next-week TODO. | 21:17 |
| smoser | k. thanks. if it happens by monday i can snif test amd64 and i386 netboot installers easily enough and verify. | 21:18 |
| rharper | is there a maximum length for launchpad userid? 32 chars? | 21:21 |
| cjwatson | rharper: No explicit limit | 21:23 |
| cjwatson | rharper: It will be rather inconvenient past a certain point :-) | 21:23 |
| rharper | cjwatson: interesting ok; right; what would you suggest as reasonable? < 255 ? | 21:24 |
| smoser | ah, but you see, rharper is implementing storage backend in launchpad user names. | 21:24 |
| cjwatson | rharper: Er, I don't know. Why? | 21:24 |
| rharper | smoser: the first rule of hidden storage backends is that we don't talk about where we're implementing them | 21:24 |
| smoser | DOH! | 21:25 |
| rharper | cjwatson: taking input to pass to ssh-import-id lp:<foo> and wanted to have a sensible limit without preventing folks from putting in their launchpad id | 21:25 |
| cjwatson | The current maximum length in use on dogfood is 496, almost certainly because at one point there was a bug in collision handling for automatically-generated names that resulted in ridiculous growth | 21:25 |
| cjwatson | I suspect names that long are not in fact in use | 21:25 |
| smoser | hm.. if you raised that to 512 it'd be much more convenient for block size. | 21:26 |
| rharper | haha | 21:26 |
| kirkland | :-) | 21:26 |
| cjwatson | The maximum name length of person rows who have an sshkey is 210 (again, on dogfood, since that's what I can query directly) | 21:26 |
| rharper | cjwatson: cool, thanks | 21:27 |
| kirkland | rharper: should I be expecting a patch from you on this? :-) | 21:27 |
| rharper | kirkland: no, no changes to ssh-import-id | 21:27 |
| cjwatson | and that's a username I really can't believe anyone is actually using, and yet it has an sshkey ... | 21:28 |
| cjwatson | maybe the victim of some peculiar renaming bug | 21:29 |
| cjwatson | everything over 64 with an sshkey either has multiple -deactivatedaccount on the end or is one of the victims of https://bugs.launchpad.net/launchpad/+bug/1099297 and thus has ridiculous amounts of junk prepended and appended to a tiny local part | 21:34 |
| ubottu | Launchpad bug 1099297 in Launchpad itself "generate_nick only seeds random state from localpart" [Critical,Fix released] | 21:34 |
| === salem_ is now known as _salem | ||
| ichdasich | heho | 23:42 |
| ichdasich | a little far fetched, but is there a valid security contact process for canonical infrastructure? | 23:43 |
| sbeattie | ichdasich: for canonical infrastructure? security@canonical.com (security@ubuntu.com is for issues with the distro itself) | 23:46 |
| ichdasich | sbeattie: kthx, did not come clear from the cannonical page | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
