=== mnepton is now known as mneptok === mhall119 is now known as mhall119|fossetc === happyaro1 is now known as happyaron [04:06] Good morning [04:07] yay, autopkgtest queues finally caught up over night === NComman`` is now known as mcasadevall === mcasadevall is now known as NCommander [06:05] 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:06] bzoltan_: yeah, i think the guy is not here anymore :D [06:06] zbenjamin: I tried to address him, but yes he is offline [06:07] bzoltan_: not even dist-upgrade worked? [06:07] zbenjamin: we need to simplify the package dependencies in the whole SDK [06:07] (what you need for ppa upgrades anyway right) [06:07] zbenjamin: no ... dist and normal upgrade simple kept back the packages. [06:08] 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] bzoltan_: right i remember now :/ [08:11] 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? [09:19] diwic, happy birthday! :) [09:19] dholbach, thanks! :-) [09:20] oh, happy birthday diwic! [09:20] seb128, thanks! :-) [09:21] seb128, FYI, I went writing some code on that subwoofer bug, but not really happy with the result just yet. [09:21] k, still quite some time before feature freeze anyway ;-) [09:36] 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:39] Mirv, what do you mean by "train not understanding trunk translation updates"? [09:39] seb128: the ticket claims unity8 has unbuilt changes, because translation updates land to trunk automatically https://code.launchpad.net/~unity-team/unity8/trunk [09:40] train just got a feature that detects trunk changes, unfortunately it doesn't understand translation updates are alright [09:40] and the publish can't be forced [09:40] don't you have a checkbox to overwrite those errors? [09:40] no, there's no force for the publish job [09:40] k [09:40] but why are some copied then? [09:41] seb128: because they're in universe and I'm MOTU [09:41] I see [09:41] thanks for the details [09:41] Mirv, copied for you [09:41] seb128: thanks, and mzanetti thanks you too! [09:41] yw! [09:50] 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] pitti, dbus ones being unhappy are what you pinged Laney about earlier right? [09:51] seb128: yes [09:51] 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] infinity, ok, I was just pointing it because it's blocking selinux which is blocking some other things [09:52] but anyway needs to sort out dbus as well, so it's probably not going to be today [09:52] do we urgently need libselinux in xenial? [09:52] seb128: oh, is that a library transition? [09:53] pitti, no, but there are a bunch of things batched with it [09:53] I was just looking at excuses [09:53] ah right [09:54] 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:55] yofel: this was the run for kio [09:55] 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] yofel: kdelibs4support/amd64 works fine against other -proposed packages, so kio does sound related [09:55] infinity: uploading glibc on a Friday afternoon, what could possibly go wrong :) [09:56] pitti: No meaningful code changes. But yes, it would explode your infra something nasty. :P [09:57] 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] pitti: (It's a Breaks against a binNMU version of something only on s390x, derp) === marcustomlinson is now known as marcustomlinson| === marcustomlinson| is now known as marcustomlinson [10:44] 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 === _salem is now known as salem_ [11:10] didrocks: Done. [11:20] 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] (link in the menu is updated, of course) [11:21] apw too ^ [11:21] * mgedmin mutters "apache rewrite rules" under his breath [11:21] 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:22] including that on the client side, possibly with auto-refresh would be great [11:22] but I'm a web/JS n00b; if someone knows how to do that, please talk to me :) [11:26] I once made apache process SSI directives in .html files: http://paste.ubuntu.com/13363773/ [11:31] pitti: You give my brain too much credit. [11:39] infinity: the entirety of what I know about internet addresses is contained in my firefox' awesome bar cache :) [11:39] pitti: Yeah, ditto, though in that case, I follow the link from the front page. [11:40] pitti: That said, if you want to fix firefox's brain, a 301 will make it rewrite the cache. [11:40] (If you have enough control to 301) [11:41] mgedmin: I know, but the .shtml page is autogenerated, so it's prone to get lost [11:44] 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:45] 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:46] 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:47] yofel: I retried teh arm64 FTBFS, seem happy now [11:47] was a weird temp issue with installing the b-deps [11:47] yofel: the test seems to work in general, as it does succeed when running against other packages, just not against kio [11:47] oh ok, I got a couple mails earlier, but if that's solved great. Thanks [11:48] ok, I'll look into that [11:48] yofel: ah, the new ones you got from this morning are real [11:48] like https://launchpadlibrarian.net/227091984/buildlog_ubuntu-xenial-arm64.kio_5.15.0-0ubuntu3_BUILDING.txt.gz [11:49] uninstallable b-deps again, looks like some ongoing transition again [11:50] dangit ^^. Ok, I'll check if it's something kde-internal anyway. [11:50] at least it's now a "real" error, not this weird "refusing to remove b-deps" one [12:22] does ubuntu-panel support panel applets, similar to DBus-based panel applets of gnome and mate? [12:29] pitti, is adt-buildvm-ubuntu-cloud supposed to work with "-r xenial" already? [12:41] VsyachePuz, there is no ubuntu-panel [12:41] 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:49] 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] pitti, I lack an example of one that works to compare [12:50] fyi my system where this is running is trusty - if that might be a reason [12:54] pitti, do we list the current MRE packages anywhere? they used to be listed on https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions === enrico_ is now known as enrico [12:59] seb128: so, may i say, that ("Application Indicators" === "Panel Applets") and ("System Indicators" === "System Tray Icon") ? [13:00] the other way around rather [13:01] system indicators are things like the sound control or the session menu [13:01] so the equivalent to applets [13:03] Windicators!!! [13:04] seb128: I want to implement "minimize to progressbar" feature [13:05] what is a progressbar? [13:05] seb128: and that progressbar should be long (i.e. 200 pixels long, not 22x22pt as an icon) [13:06] seb128: https://en.wikipedia.org/wiki/Progress_bar [13:06] yeah, I know what that widget is [13:06] but "minimizing to a progress bar" is not a concept I grasp I think [13:07] seb128: I have an application which have an UI for making queries, and performs long frocessing for each query [13:07] I want to minimize it, but track the completion of operations [13:08] the concept is "minimize to tray", but I used it as an analogy [13:08] well, use an appindicator [13:09] i don't want small icon, i want long widget [13:10] may be even several of them [13:10] one for each query [13:12] that's not possible [13:13] you can have the status/summary in the indicator menu though === dpm is now known as dpm-afk [13:17] 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:18] VsyachePuz, indicators can only contain a label or an icon in the panel [13:18] no custom rendering or other widgets [13:26] cpaelzer: the host system shouldn't matter that much; but I highly recommend using a current autopkgtest version [13:28] 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] coreycb: they are gone, we generalized the SRU policy instead [13:28] coreycb: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html [13:28] pitti, ok thanks [13:35] seb128: what is "icon"? Can it be nonsquare? Can it be 200x22px ? [13:36] seb128, thanks for the gdal rdep rebuilds [13:38] pitti, yeah seems so on my wily system it just worked [13:38] pitti, I'll try updating to a more recent autopkgtest on my Trusty and try again [13:40] pitti, just FYI here would be the full log that worked http://paste.ubuntu.com/13365391/ [13:40] and the difference starts at some cloud-init things, so yes it could be just as you suggested [13:40] I'll let you know later if it worked [13:53] stgraber: hm, that i386 lxcfs failure seems fairly resistant against retries: http://autopkgtest.ubuntu.com/packages/l/lxcfs/xenial/i386/ [13:55] mterry, yw [13:55] VsyachePuz, I don't know, I guess you can try [13:56] kenvandine, poke about that deja-dup branch [13:58] xnox, are you going to address the cmake merge? [13:58] doko, well, i win the TIL... [14:00] xnox: You do now, anyway. :P [14:00] doko: Shame about your versioning breaking the merge a bit, though. [14:00] doko, i believe steve tricked me into doing that, via infinity. [14:01] xnox: Oh, I guess you could work around the version issue by merging from experimental, if you're feeling bold. [14:01] (Might want to test in a devirt PPA first...) [14:04] mterry, sorry... i will look at it today! [14:05] kenvandine, no worries :) [14:06] good morning! [14:06] mterry, actually this MR isn't nearly as big as i thought... i don't need to worry about the vapi :) [14:07] kenvandine, but that's where I hid all my bugs! [14:08] :) [14:13] 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] https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770 I documented the fix I ended up doing, here. [14:13] Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed] [14:15] mterry, to test this, i just need to uninstall duplicity right? [14:15] and run deja-dupe, which should prompt to install it? [14:15] kenvandine, yeah should do [14:15] kenvandine, specifically, run either of the preferences interfaces (running deja-dup from command line will just give an error) [14:25] 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] VsyachePuz, if you say so [14:25] VsyachePuz, to me it looks like an icon with a menu [14:25] it's 3. [14:27] seb128: ok, i am wrong. first looks like gnome workspace switcher [14:30] VsyachePuz: and the MATE one [14:30] gnome2 that is [14:30] I have it on my monitor just in front of me [14:30] my fav 'cause it has window shape, and icon for fullscreened windows [14:31] and, well, 'cause MATE === dpm-afk is now known as dpm [14:41] nemo: yes, I set wanda fish to 0 frames, and panel height to 64 pixels. Receive long image without problem. [14:42] 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:43] and only one bar [14:44] There is also WingPanel from Elementary OS, it allows widgets and AppIndicators, but didn't find specs [14:45] 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:59] 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] 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] ticket with QA Granted approval at https://requests.ci-train.ubuntu.com/#/ticket/242 [14:59] VsyachePuz: indeed [15:00] morphis is your point of contact regarding the silo itself [15:05] pitti, I can confirm after updating autopkgtest to 3.18.1 it works on my trusty system - thanks [15:05] cpaelzer: great [15:05] 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:06] cyphermox, seb128, pitti: is that silo something you could help with at all please ^^^ [15:06] VsyachePuz: not at all, just pointing something that I saw that could help you [15:06] mterry, i'm also seeing an error trying to install [15:06] The version 0.7.01-1ubuntu1/Ubuntu of duplicity isn't available. [15:07] didrocks:seb128: thanks [15:07] yw [15:08] mterry, oh... i think i know why [15:08] hm [15:14] mterry, apt currently isn't happen with keys on my desktop :) [15:14] i bet that's causing packagekit to barf [15:14] kenvandine, keys? [15:15] apt spews GPG errors right now [15:15] oh ah [15:15] i need to sort that out, just haven't had time [15:15] mterry, i'm more concerned with the test failures, ideas? [15:16] kenvandine, test failures? Oh, I hadn't noticed. Let me run tests again [15:16] in package build http://paste.ubuntu.com/13365813/ [15:16] kenvandine, say what [15:16] weird [15:17] * mterry will try to reproduce, maybe that's only in a chroot [15:21] mterry, i fixed the gpg issues in apt and it's still failing to install [15:21] same error message [15:22] Laney, we have webhooks now, right? can transition tracker update itself everytime there is a push to the config branch? [15:22] mterry, could it be a missing depends? i don't have packagekit installed :) [15:22] kenvandine, I think you just need libpackagekit [15:22] kenvandine, it talks to aptdaemon [15:23] ah [15:23] kenvandine, nothing in this branch is working for you! :) [15:23] so not it [15:23] nope :/ [15:24] cyphermox, seb128, pitti: anyone having time to help merging that silo? [15:24] morphis, "that silo"? [15:24] I lack context [15:24] morphis: looking... [15:24] k, seems cyphermox is on it ;-) [15:24] 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] ticket with QA Granted approval at https://requests.ci-train.ubuntu.com/#/ticket/242 [15:24] cyphermox: thanks! [15:24] awe: ^^ [15:24] oh, that's landing, great! [15:25] seb128: yes, finally :) [15:25] hum, wat [15:26] w00t! [15:27] seb128, looks like we have a fix for qt dbus too [15:27] awe, this week is a good one :-) [15:27] and way to wrap it [15:29] seb128: one of the next steps is to sync the landings of bluez on desktop and Touch [15:29] morphis: is indicator-bluetooth just a port to bluez5? that's not so obvious from the changelog [15:30] cyphermox: it is and just and merge with what is in wily/xenial [15:30] no further changes [15:30] morphis, right [15:32] I wasn't aware that we could permit this kind of very obvious deviation from SRU/backport rules for a stable release [15:33] huh? [15:33] cyphermox: overlay is treated differently vs features from actual Ubuntu releases [15:33] isn't this a landing to the PPA? [15:33] 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:34] um, no [15:34] not for bluez5 [15:34] that would be super risky [15:34] cyphermox: The overlay is pretty Wild West. Sadly. [15:34] if folks want bluez5 on the desktop, they upgrade to wily [15:34] cyphermox: Its entire raison d'etre is to circumvent SRU policy. :P [15:34] this isn't a case of wild-west [15:34] we landed bluez5 in wily [15:35] and are backported to just touch [15:35] as it's a huge change [15:35] and requires lots of QA [15:35] it'd be way too risky to SRU [15:35] and AFAIK, nobody is asking us to [15:36] 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] infinity: well, most things that happen in the overlay should still not just happen in the overlay, but backporting bluez is special [15:36] desktop can be installed on an order of magnitude more devices than a touch release [15:36] not a fair comparison at all [15:36] 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:40] morphis, indeed [15:41] morphis: so why does bluez have +15.04.20151023? just because silo, or is that frankensteined or a git cherry-pick? [15:41] cyphermox: it's landing through the citrain [15:41] and the origin for this is a MP [15:41] ok, that's what I thought [15:43] 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:44] (and upstream as appropriate) [15:44] cyphermox: that is the plan [15:44] I really want to align bluez uploads for current devel and phone [15:44] so that we upload the same to both together [15:45] but that is one of the next steps [15:45] I'm preparing a new kdump-tool package which require a change in its config file (/etc/default/kdump-tools) [15:45] what should the maintainer script do : display a warning ? [15:45] I also need to add a prompt to enable it by default [15:46] what is the appropriate way to address such a situation ? [15:46] 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] kenvandine, how are you running it? [15:46] caribou: was /etc/default/kdump-tools being shipped as a conffile previously? [15:46] rbasak: yes [15:46] caribou: then you can just update it, and dpkg will take care of the prompt. Unless you want to avoid the prompt somehow. [15:47] kenvandine, ahem, accidentally pushed to trunk, will fix that [15:47] caribou: ah, but adding a prompt to change the file based on the answer is trickier. [15:47] mterry, i just did a 'bzr bd' [15:47] morphis: same applies to pulse, I think we should have HSP support patches there too, and upstreamed, etc. [15:47] 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:48] rbasak: two config variable that were not used previously are expected to be enabled now [15:48] (i.e. they come with the new conffile) [15:49] cyphermox: yes, but as already said, that is the next step [15:49] If the user blindly picks to keep the old conffile then there will always be problems IMHO. [15:49] cyphermox: take this for all changes in silo 43 [15:49] So I wouldn't be too worried about that case. [15:49] mterry, any ideas why it's failing to install? [15:49] 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] rbasak: ok, just wanted to be sure that showing a warning was not required [15:49] kenvandine, no, that also worked for me last time I tried it [15:50] mterry: The version 0.7.01-1ubuntu1/Ubuntu of duplicity isn't available. [15:50] that version string looks odd, with the /Ubuntu in it [15:50] 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] rbasak: well, in wily & xenial, kernel crash dump will fail if they're not enabled :-/ [15:50] but i don't think your code is involved in that [15:50] kenvandine, it's also an old version [15:50] mterry, i'm on vivid + stable overlay [15:50] 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] kenvandine, what release are you on? [15:50] kenvandine, ah hrm [15:50] cyphermox: yes [15:50] kenvandine, why? ;) [15:50] 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:51] Since if it does dpkg will think the user modified it. [15:51] mterry, that's what i'm developing for right now :) [15:51] and xenial! [15:51] i'll switch soonish :) [15:51] mterry, do you think that's why it's failing? [15:51] kenvandine, looks like tests work for me in bzr bd too (just sanity checking) [15:51] kenvandine, probably not? [15:52] imma try again on my machine to install [15:52] cyphermox: btw. does anything speaks against releasing bluez through citrain with MP to xenial as well? [15:52] mterry, i already have libpackagekit-glib2-dev [15:52] kenvandine, yeah, if you didn't, it wouldn't even build [15:52] morphis: not really, aside from that it shouldn't be an MP, it should be a direct upload [15:52] that way we don't have outlanding version numbers [15:53] which makes a coordinated review process pretty hard [15:53] ie. we should be more or less in line with the debian packaging if possible, and not have special versions [15:53] no [15:53] mterry, could the test failures have anything to do with me being on vivid? [15:53] 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] it's the same review in silos [15:53] kenvandine, I also doubt that [15:53] i wouldn't think so [15:53] cyphermox: so where do I do my review then? there is no real instance I can put my comments in [15:54] morphis: do it in a bug [15:54] if you want to do things in a MP, you're free to keep stuff there [15:54] but the upload through the silo shouldn't be via a MP [15:54] kenvandine, ok install worked for me (w/ deja-dup-preferences, but "unity-control-center deja-dup" crashes for me!) [15:55] kenvandine, so I'm going to look at that crash [15:55] should work just the same as NM, basically. you have a packaging branch, just it's not relevant to the silos [15:55] kenvandine, and I can't explain either of the failures you see [15:55] i'm building in sbuild now [15:55] caribou: agreed [15:55] caribou: that part is fine. [15:55] that is, unless there's a way to use the MPs anyway but not having version number mangling because of it [15:55] kenvandine, what does "apt-cache policy duplicity" say? [15:55] rbasak: ok, thanks! [15:55] 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] Installed: (none) [15:55] Candidate: 0.7.01-1ubuntu1 [15:56] caribou: because then the user will get an unexpected dpkg prompt on a future upgrade. [15:56] cyphermox: so where can I comment then directly on the source which is landing in the bug? [15:56] morphis: I don't know what you mean by that [15:56] rbasak: the conffile will come with the default, so choosing the default will not modify the conffile [15:56] caribou: what if the user chooses the non-default? [15:57] rbasak: then we would want him to confirm that he changed the default behavior on the next upgrade, right ? [15:57] 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] rbasak: default being kernel crash dump is enabled [15:58] caribou: no, then the next upgrade should remember what the user asked for and make it continue to happen without prompting. [15:58] 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:59] rbasak: ok, then the script will check if a previous value exist (I suppose that it is the expected way to do) [15:59] 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] caribou: there are a few different ways of approaching this. ucf might be appropriate here. [15:59] rbasak: that's the first time I do one from scratch, I'll fetch a few example in other packages [16:00] 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] mvo: what can be longer than infinitty ? [16:00] caribou: lol [16:01] mvo: 2.0, you say? [16:01] 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] 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] 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] where in the last two steps through the manual process something can be added to the package which I didn't reviewed [16:03] caribou: sure [16:03] morphis: what? [16:03] 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:04] 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] cyphermox, it's something I've pointed out in the past as well [16:04] cyphermox, I thought this was about a landing to the PPA? [16:04] 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] xz indexes would be really nice. Thank you for working on it! [16:04] awe: it is [16:05] awe: notice I said in the archive, and I let your silo through already [16:05] cyphermox, thanks [16:05] which, in retrospect, was wrong because now it's be always higher than anything unless we upload 5.36 [16:05] Yeah, that shouldn't be in the overlay either. [16:06] cyphermox: thanks! [16:06] If it was copied to the overlay, please get someone to delete it and re-upload with a sane version. [16:06] oh, but we do have 5.36 in xenial [16:06] Or, I guess, if xenial is already higher, whatever. [16:06] infinity: I'm tempted to not care for this case because xenial is already higher, yeah [16:06] But distro packages with a proper orig shouldn't be re-packed with strange versions for silos. [16:07] 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] cyphermox, infinity: why don't we modify citrain then to do proper version numbers for those packages? [16:07] 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:08] morphis, +1 [16:08] morphis: by all means. [16:08] robru: sil2100: ^ [16:08] there are multiple things: [16:08] having a MP gives us a review protocol with all things documented [16:09] all back and forth [16:09] 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] which isn't reviewed by others [16:09] nobody would include anything else when doing a direct upload to the PPA [16:09] 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:10] cyphermox, but they *could* [16:10] those who have access to do it are expected to know better, unless they have a very good reason [16:10] exactly [16:10] meh [16:10] people can make mistakes [16:10] it's a valid point [16:10] if we have the automatic to do such things why don't we use them? [16:11] morphis, we do [16:11] primarily for packages developed by Canonical [16:11] it gets trickier when we're talking about packages that we mostly maintain [16:12] but I don't see any reason not to use them (optional) for other components too if the maintainer / developer wants to [16:12] my primary reason for bluez is that we have to coordinate now between different kinds of users [16:12] Desktop, touch, IoT [16:13] which brings in a bunch of different use cases and we have to ensure nothing breaks any of those use cases [16:13] morphis, sure... except there are some problems when doing so. One being the version mangling [16:14]