=== _salem is now known as salem_ [01:45] Bluefoxicy: you could file a bug and use the tag upgrade-software-version [01:46] since monodevelop is currently synced with Debian, you can also file a bug against the Debian package, severity wishlist === salem_ is now known as _salem [07:43] Good morning [08:18] morning pitti! are you up for looking at pandas LP: #1643151 ? fewer removals needed now [08:18] Launchpad bug 1643151 in sunpy (Ubuntu) "Please remove sad pandas and friends" [Undecided,New] https://launchpad.net/bugs/1643151 [08:28] ginggs: I really don't like removing pandas, they are endangered and cute!! [08:28] ginggs: (looking ☺ ) [08:29] turning them into happy pandas is a way to remove sad pandas :) [08:29] pitti: true, but they have reproducibility problems [08:29] ginggs: so maybe you should add a Depends: to sextractor? [08:43] ginggs: hmm, do you have a list of all binaries that need to be removed? [08:43] * pitti is piecing them together with reverse-depends, but you may already have it [08:44] pitti: sorry i don't have a single list with all of them handy [08:45] ok, nevermind [09:04] ginggs: http://paste.ubuntu.com/23622919/ ← looks plausible? [09:05] (took a bit, some binaries are weird) [09:05] pitti: looks way more than i expected, let me check [09:07] pitti: libsopt* shouldn't be on that list, it no longer depends on pandas [09:07] ginggs: that's reverse-depends and binaries of reverse-build-depends, minus packages that are only in -proposed [09:09] ginggs: ok, dropped [09:12] pitti: thanks very much [09:12] ginggs: rest looks good? [09:12] oh wait [09:13] i misunderstood what you meant by dropped [09:13] pitti: glueviz (and others) only build arch:all packages [09:14] ginggs: but these still need to be removed on these arches [09:14] .. I think [09:14] well, they would come back next time it gets built, but they would be uninstallable [09:15] but there is no such thing as glueviz 0.9.0+dfsg-1 arm64 binary, is there? [09:16] it's published there [09:16] I don't think it makes much of a difference -- it's either present and uninstallable, or not publshed there, but will come back with the next build [09:18] pitti: i don't understand. where do you see glueviz is published for arm64? [09:18] glueviz | 0.9.0+dfsg-1 | zesty/universe | source, all [09:18] ginggs: well, if you prefer I can remove them, if you have a list of arch:all packages from that list [09:18] i was just going to paste that [09:19] but I'd rather remove it from these arches too [09:19] pitti: so rmadison says source,all - i don't see arm64, but i'm just not understanding, so please go ahead [09:19] ack [09:27] fossfreedom: hey! Let me take a look at your cdimage merge in a bit :) [09:31] sil2100 - thanks! [09:45] pitti: thanks for dealing with those pandas, it was the humane thing to do [09:45] heh [09:47] pitti: if you're doing removals, could you look at bug 1649163 ? [09:47] bug 1649163 in ubuntu-mobile-default-settings (Ubuntu) "Please remove ubuntu-mobile-default-settings from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1649163 [10:01] jbicha: done [10:01] looks like plasma-framework is blocking mesa, test on s390x has failed since quite a time [10:01] thanks [10:05] tjaalton, right. but i'm pretty sure plasma-framework does not care about s390x. [10:06] infinity, could you please do the hints magic for plasma-framework s390x test? ^ [10:06] that too [10:23] xnox, cjwatson: does haskell defaults to -O0 on s390x? [10:25] hmm, haskell-xmlhtml builds in unstable [10:26] doko, i didn't think so. i thought the "advanced" haskell was missing with some fancy features. [10:26] whatever that thing was. [10:29] maybe that's not true any more. ghc provides look the same and have ghc-dynamic and ghc-ghci [10:30] doko, you are looking at rebuild results? [10:30] yes, but gcc-7 only for now [10:31] https://launchpad.net/ubuntu/+source/haskell-xmlhtml/0.2.3.5-3 [10:31] did not build on s390x in release.... [10:31] right, but the file succeeds to build when -O1 is used [10:31] =( [10:32] I assume this is our limitation on memory/swap [10:32] $ wc -l ghc_12.i [10:32] 5146360 ghc_12.i [10:32] -rw-rw-r-- 1 ubuntu ubuntu 207693501 Dec 13 10:15 ghc_12.i [10:32] Error: Ubuntu bug 207693501 could not be found [10:33] try 207693502 ;p [10:33] try ubuntu 207693502 ;p [10:33] Error: Ubuntu bug 207693502 could not be found [10:33] heh [10:38] Hi, I'd have an MRE question [10:38] I know that for a totally new version one has to upload the new orig tarball, but I wondere how that works with an MRE [10:38] zesty already has the newer orig tarball - so one could say LP has it [10:38] but (so far) yakkety does not [10:39] now I want to properly upload this for MRE and wonder if I have to set -sa or not on buildpackage to include the orig tarball on the upload [10:42] cpaelzer, largely irrelevant. either your upload will be rejected straight away, or will hit the unapproved queue. [10:42] cpaelzer, you can use -sa alway... and launchpad will discard duplicate tarballs for you. [10:49] xnox: thank, the latter is interesting as I thought to read a warning that it might be rejected if it has one already [10:49] xnox: I cant find it but maybe that triggers only if it is different which might be a perfect case to reject it [10:53] xnox: ah here dput is what is telling me "Package includes an .orig.tar.gz file although the debian revision suggests that it might not be required. Multiple uploads of the .orig.tar.gz may be rejected by the upload queue management software." [11:02] xnox: nice, apt full-upgrade on my VM marks libcgmanager0 and upstart for auto-removal [11:02] xnox: thanks for landing unity-greeter! [11:03] cpaelzer, be a rebel, ignore warnings. [11:04] cpaelzer, launchpad enforces that checksum of the .orig.* in the .dsc remains the same. whether you upload one (again) or not is irrelevant, as long as there is at least one. [11:04] at least one copy. [11:04] xnox: I still have indicator-network running (from gnome-session), that's still outstanding or unexpected? [11:05] pitti, still outstanding [11:05] * cpaelzer is not so rebel-ish most of the time, but thanks for the quote xnox - I feel safer now! [11:05] pitti, i have a branch somewhere for it, but not landed yet. [11:22] sil2100: thanks for the review. Much appreciated. [11:24] sil2100: I presume the DMB needs to officially approve ~ubuntubudgie-dev ? [11:25] fossfreedom: I think so! I need to bring this up with them as enabling a new flavor is something new to me! [11:25] ah - makes sense. [11:25] fossfreedom: it looks good to me so far but I think the DMB would need to take ownership if it, but that might be the TB's responsibility [11:25] Quick question if I may? [11:25] Sure [11:26] The seed "owner" is me - I'm fuzzy how to upload a bzr branch as a team (ubuntubudgie-dev) rather than myself. Any thoughts? [11:27] fossfreedom: if you go to the seed branch details, you can then go to 'Change branch details' [11:28] fossfreedom: there you should be able to change the owner [11:28] looking... [11:28] fossfreedom: once you do that you should still be able to bzr push to it as normal since you're a member of the team [11:30] sil2100: thanks - I think that worked. the branch is now called "lp:~ubuntubudgie-dev/ubuntu-cdimage/ubuntu-cdimage" [11:31] \o/ [11:31] Same for the seeds? === _salem is now known as salem_ [11:34] sil2100: think that's done as well - lp:~ubuntubudgie-dev/ubuntu-seeds/ubuntu-budgie.zesty [11:35] fossfreedom: excellent, I'm poking around to see if we can get the team officially blessed [11:35] Need to find out who has the power to do that - is it the TB after creating the packageset or can it be us for now [11:36] sil2100: you sir are an officer and a gentleman. Thanks! [11:38] yw! Sorry it looks a bit chaotic so far [11:59] pitti, hi, it is reported that docutils breaks sphinx autopkgtest, but is it possible to retry that with the proposed version of sphinx rather than the release one? [11:59] Also, I get 500 internal server errors when trying to retry the tests :( [12:03] mitya57: add extra &trigger= to the URL [12:03] * Laney just tried a retry and it worked, maybe transient [12:04] Laney, You submitted an invalid request: Malformed trigger, must be srcpackage/version [12:05] URL? [12:05] I.e. it was https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=sphinx&trigger=python-docutils%2F0.13.1%2Bdfsg-1 [12:05] And I changed it to https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=sphinx&trigger= [12:05] oh [12:05] &trigger=package/version [12:06] Laney, what should I replace python-docutils/0.13.1+dfsg-1 with? [12:08] you should add &trigger=sphinx/theversioninproposed if you want it to get that too [12:11] to the URL that you get from excuses.html, that is [12:11] Just append it on the end [12:12] * Laney . o O ( where else would you append it? ) [12:13] * mitya57 finally got it [12:13] Laney, thanks! [12:14] mitya57: yw [12:14] looks like sphinx itself has a few red tests, would be good to look at those [12:15] I've looked at most logs, they don't even mention sphinx — so something unrelated [12:16] But some packages definitely need fixing, like hovercraft which I'm looking at right now [12:18] nod [13:02] ugh, this is the worst interface [13:02] * Bluefoxicy just finds a way to file bugs, then modifies the URL in launchpad to not be stupid. === marcusto_ is now known as marcustomlinson [13:33] Okay, not sure if I did that right, but now Launchpad #1649580 also references Debian Bug #848038 [13:33] Launchpad bug 1649580 in monodevelop (Ubuntu) "Update Monodevelop to 6.1" [Undecided,New] https://launchpad.net/bugs/1649580 [13:33] Debian bug 848038 in monodevelop "Monodevelop upgrade to 6.1 in Sid" [Normal,Open] http://bugs.debian.org/848038 [13:34] I'm not sure if Ubuntu even has a Mono team anymore === hikiko is now known as hikiko|ln [13:59] pitti, re: pandas we missed removing python3-feather-format arm64, will you do it please? [14:00] ginggs: *flush* [14:00] pitti: thanks [14:05] robru: is there a way to splot the bileto associated autopkgtests in the queue to get an ETA feeling ? [14:05] cpaelzer: PPA queues are zarro (http://autopkgtest.ubuntu.com/running) [14:06] pitti: ok, so I learned the source is the ppa queue [14:06] pitti: but I'm missing my automated sign-off, how would I get to logs or so [14:06] sorry, just too new to bileto in that regard [14:06] url? [14:07] pitti: https://bileto.ubuntu.com/#/ticket/2290 [14:07] cpaelzer: actually, there's one unity8 run for ticket #2233 queued [14:07] ... so not that [14:07] should be libvirt [14:08] cpaelzer: hm, it didn't even start testing yet -- there is no link to an excuses page [14:08] " No packages are being considered! If you are preparing sources manually, please upload them to the PPA now." [14:08] I suppose you did that as the PPA has a libvirt [14:08] pitti: they are in the ppa [14:08] yes [14:09] cpaelzer: sorry, can't say, deferring to roaksoax [14:09] err, robru [14:09] pitti: and I checked the "Lander Signoff" which according to Bileto docu is the next to kick of britney [14:09] pitti: thanks for thinking through the basics with me, waiting for robru then [14:09] robru: ^^ [14:10] rbasak: Hi,got a minute to discuss the isc-dhcp / isc-dhcp-ddns issue ? [14:10] cpaelzer: try to click the "diffs" button perhaps? that's the one it keeps complaining about, not sure [14:12] pitti: where are you seeing "no packages..."? That's quite an old status, not relevant [14:12] robru: I just checked the audit log for anything that might stand out [14:12] cpaelzer: indeed, the"missing diff" status is why autopkgtests aren't running [14:12] robru: I didn't expect you to be awake at this hour, jetlag FTW? :-( [14:12] pitti: yes quite jetlagged [14:13] ok, hitting regenerate diffs now - didn't know that was a blocking step === scottt is now known as Guest41818 [14:14] cpaelzer: yes, for tickets built from merges, it generates the diff at the same time it generates the source packages. When you upload manual sources though it doesn't get a chance to do that so you have to do it manually [14:14] caribou: yes. Would a hangout be easiest, maybe with slashd? I don't see him online though. [14:14] This is one of the pain points that makes MPs first class and source packages second class [14:15] robru: ah, that actually makes sense -- there's no way of telling when the dev is done uploading bits to the PPA [14:15] rbasak: yes he is, spoke to him earlier. Let me set it up [14:15] I'm fine to note it and press it into my muscle memory over time, just didn't know [14:15] caribou: ack [14:15] robru: although the "build" button would be slightly less confusing than the diffs one, I suppose [14:16] pitti: for a while there was some code to auto diff but it was error prone, often triggering at inopportune times [14:16] robru: but now generating diff failed I think, is ended with Diff missing - is there something I could do about that? [14:16] pitti: build and diff buttons are indistinguishable if you don't have MPs [14:18] cpaelzer: sigh, that's a race condition. Can you file a bug against lp: bileto please? Just say "status at end of diff job fails to notice new diffs" [14:18] robru: sure I can file one [14:19] robru: what can I do now to trigger britney for me in the meanwhile? [14:20] cpaelzer: nothing. You need to wait up to ~20 min for the status to correct itself, then you should see "successfully built" along with "automated signoff: queued" [14:20] robru: ok, thanks that is fine for me [14:20] You're welcome [14:20] as long as I know it will continue to stumble forward I'm fine - just don't want to know it blocked [14:21] cpaelzer: ping me again if it doesn't say "successfully built" within 20min but it should be good [14:21] robru: ok, will do so - until then you now have bug 1649595 to track [14:21] bug 1649595 in Bileto "status at end of diff job fails to notice new diffs" [Undecided,New] https://launchpad.net/bugs/1649595 [14:22] Thanks [14:25] Laney: did you find out a system how to rebuild the gnat packages? [14:26] doko: no, just finding ones which fail autopkgtests === hikiko|ln is now known as hikiko [14:45] pitti: hi. sorry to hear you're leaving [14:45] been good working with you [14:45] had a question before you go, though [14:45] how should I go about getting stuff into python-dbusmock from now on? [14:45] pete-woods: what would you put into python-dbusmock? [14:46] dobey: nothing this very second [14:46] pete-woods: no change really; I keep maintaining this project on Github and debian [14:46] pete-woods: I'll probably just stop worrying about the overlays, but I figure you can do that yourself [14:46] pitti: hmm, probably not, but I can learn :) [14:47] pete-woods: sure. just seems like if it's a new module to mock something it should go into the project it's mocking, not python-dbusmock :) [14:47] pitti: thanks for the info :) [14:47] dobey: this would be things like the NM template, and general fixes, though [14:48] ah ok, though i'd say someone really needs to get the NM template upstreamed [14:49] aww there isn't a cups template in dbusmock. doh [14:50] but then I need to push updates to network-manager [14:50] which would likely be super slow [14:50] my gut feeling is that keeping the templates in dbusmock is easier all around [14:51] * pete-woods still doesn't know where he'd be in Canonical without pitti's dbusmock [14:52] probably having had a breakdown somewhere around the 1 year mark and quitting [14:52] robru: it kind of worked, I got a ping in ubuntu-ci-eng that it built, and automated signed off switched to queued - but I still can't find it anywhere on http://autopkgtest.ubuntu.com [14:52] you might have written it yourself? :-) [14:52] pitti: I'd have tried. but my python-fu isn't that strong [14:52] robru: neither queued, not failed/succeeded - if you spot it let me know where to look for it [14:52] it'd probably have been a C++ project, and been very tough [14:53] pete-woods: not that hard. i implemented something similar before dbusmock existed :) [14:53] cpaelzer: no you're confused. "Queued" in bileto doesn't mean "i triggered your autopkgtests", it means "this is in the queue of things to have autopkgtests triggered for" [14:53] to make it as flexible as python-dbusmock I think it might have been [14:54] mostly it's just busy work [14:54] you can just stuff code in strings with python [14:54] pete-woods: most of it isn't rocket science, but writing the generic method mocks and poking in dbus-python's innards was an interesting research exercise [14:54] Eg, eventually britney will see it and trigger autopkgtests [14:54] yeah, writing it in C++ would have been limiting for sure [14:54] robru: very meta that is - thanks for un-con-fusing [14:55] but i can't say that i enjoy writing python inside strings in c++ as a means of writing tests, either :P [14:55] dobey: OOI, why would you? [14:56] dobey: dbusmock's primary interface is, well, d-bus, not python [14:56] well, the function bodies need to be python, sure (but usually they are trivial half-liners) [14:56] cpaelzer: it's unfortunately a limitation of britney. It doesn't just trigger autopkgtests, it also does silly things like "load entire Ubuntu archive into memory", so this means it can only inspect one ticket at a time (is impossible to run two in parallel, you get OOM), so it takes a while to churn through all the tickets [14:58] cpaelzer: eventually your ticket should say "running" and then at that point you can expect them to show up in autopkgtest infra [14:58] robru: well, it does super-polynomial computations over the archive graph (although in almost all practical cases i's O(n²), but you really don't want to do that on-disk :) [14:59] pitti: yes, but it is quite the bottleneck when all you want is to trigger autopkgtests [14:59] robru: well, you still want installability tests too, no? [14:59] robru: but how do you know what to trigger, without inspecting the archive graph? [14:59] robru: you already disable second-stage installability, but at least the package itself should be installable in its own right [15:00] and rdepends calculation needs the entire archive map too [15:00] for britney's original intent (running once for every distro) that's quite fine [15:00] pitti: i suppose [15:00] the thing to optimize for britney would be to only do that initial loading/map building once, instead of once per silo [15:00] or maybe pickle it out [15:00] Ooooooooooh pickle [15:01] or whatever the fastest serialization is these days :) [15:02] Poor cpaelzer just wants autopkgtests run and here he has to wait for britney to poke every other ticket before his. Autopkgtests can run in parallel but britney has to run each ticket in series before it even notices to trigger them [15:03] robru: she's your's now, have fun teaching that rascal :) [15:04] pitti: if CI train is and indication, i suppose i will spend the next 4 years rewriting it from scratch, twice [15:04] haha [15:04] robru: once in Go, and the final version in Haskell :) [15:06] pitti: did you know m4 is Turing-complete? I once wrote a prime-number calculator using nothing but m4 macros [15:07] nice [15:07] robru: I do know that C++ templates are -- I've seen a crazy project which actually uses that in uni time [15:08] Heh. [15:44] cjwatson : wgrant : can you please help with lp bug 1609128? (i tried to find you a few days ago, here's some context https://irclogs.ubuntu.com/2016/12/07/%23ubuntu-devel.html#t16:24) [15:44] Launchpad bug 1609128 in lazr.authentication "PyPI metadata is wrong" [Undecided,New] https://launchpad.net/bugs/1609128 [15:46] yeah, rolling an updated release is on my to-do list, but I'm behind on a bunch of code I need to write first [15:48] cjwatson : i see thanks. waiting eagerly [15:48] ~/wg 119 [15:48] oops [15:51] pitti, I guess now's a bad time to ask you if you feel like maintaining a web browser? ;) [15:52] chrisccoulson: slight grammar -- I'll be maintaining something that runs *in* a web browser :) [15:52] heh [15:53] pitti, it looks like it's going to be a lot of fun anyway :) [15:55] chrisccoulson, hey, aren't you supposed to be on holidays? ;-) [15:55] seb128, yep. I'm back temporarily, thanks to adobe and mozilla [15:55] oh right [15:56] the fun never stops for you, I almost forgot [15:56] ;-) [15:56] "fun" ;) [15:56] didn't you have a release to get out on newyear or something last year? [15:56] * seb128 doesn't remember the details [15:57] seb128, last year it was flashplayer, 28th december [15:57] well, dec 13th is better! [15:57] I don't really understand how I ended up with flash tbh [15:58] can we just leave it broken, and may it never come back? [15:58] heh [15:58] honest question: does anyone actually encounter flash on any non-pr0n web sites these days? [15:58] chrisccoulson, hope your enjoy your holidays once that round of updates is done! [15:58] I haven't had it installed for several years, but of course everyone uses different websites [15:59] pitti, I don't know. I struggle to find sites to test it with now. BBC News still seems to require it too [15:59] we can thank Android and phones, I think [15:59] s/too/though/ [15:59] pitti, I think the website they use for the townhall calls does [15:59] I couldn't use it on my firefox last time [15:59] anything that doesn't work on a mobile browser basically ceased to exist, no? [15:59] seb128: bluejeans? [15:59] yes [16:00] getting rid of flash and convincing seb128 to maintain firefox should be my new years resolution [16:00] seb128: right, I had to use chromium for that one, not sure if it was a codec or flash issue [16:00] chrisccoulson, let's see how convincing you can be ;-) [16:00] seb128, beer? [16:01] lol [16:01] seb128 only responds to absinthe [16:01] beer is a start [16:01] ice cream has been observed to have a measurable effect too [16:01] not sure it's going to enough to make me agree to maintain firefox though [16:01] and stollen [16:01] Laney, shusssh [16:02] * seb128 is hungry now [16:02] me too [16:02] I've already over-eaten though and it's only dec 13 [16:07] pitti: flash is still commonplace on websites aimed at kids, I find [16:08] flash is sadly still commonplace in way too many places :( [16:08] ah -- I wasn't trying to troll (much), but genuinely interested [16:08] pitti: i had to use flash yesterday to listen to a company video conf call :) [16:08] I surely wouldn't look at kid's websites, so that's a good data point [16:09] pitti: some banks use flash for certain features still [16:18] TTFN -- time to start the EOY holidays, IRC-less; I wish you all some nice resting and time with your family, see you back in January! [16:18] have fun! [16:19] pitti, all the best! [16:19] enjoy pitti ! [16:20] all the best pitti [16:22] pitti: bluejeans - our company site for commuication from our great leaders... [16:29] slangasek: so I got the zend* stuff mostly sorted in zesty. But I think it's currently stuck because there is one binary package that disappears in the transition from src:zend-framework to src:zendframework (libzend-framework-zendx-php). I documented this drop in the changelog, but perhaps I should have indicated in the control that zendframework Breaks libzend-framework-zendx-php? It doesn't provide [16:29] or replace it, though. Just looking for some guidance on how to resolve the transition === shuduo is now known as shuduo-afk [16:44] juliank, mvo: today i learned what "rc" status stands for. Finally apt search told me that it's for [residual-config] [16:45] i always thought that it was strange to call leftover configs as "removed-configs" [16:46] xnox: heh [16:47] what does rc mean in /etc? [16:47] xnox: It actually stands for remove config-files [16:47] That is, the package is selected for removal in dpkg; but still has config-files on the system [16:47] "run commands" apparently [16:47] * Laney gets a history lesson [16:48] * xnox thought rc stands for stable software [16:49] bdmurray: I hadn't looked at bug 1640823 again, no. Shall I review and release if appropriate during my SRU day tomorrow? [16:49] bug 1640823 in util-linux (Ubuntu Trusty) "[trusty] mount -o loop is limited to 8 loop devices" [Undecided,Fix committed] https://launchpad.net/bugs/1640823 [16:49] xnox: remote control [16:50] rbasak: Since you had an opinion I think that's appropriate [16:51] bdmurray: OK will do, thanks. [16:57] nacc: libzend-framework-zendx-php, is this something that would have been a top-level package users would install? [16:59] slangasek: yeah, it's a leaf package with no rdeps [17:01] barry: fyi, i've refreshed my snap, i just need to verify it still works :) [17:04] nacc: nice [17:09] slangasek: or is this a consequence of needing to also delete src:zend-framework from zesty (see: LP: #1593024 c#14) [17:09] Launchpad bug 1593024 in zend-framework (Ubuntu) "Unblacklist and sync zendframework 1.12.18+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1593024 [17:09] nacc: so, that means someone who has that package installed will have a somewhat rocky upgrade (basically, what trips update-output can also trip a user upgrade). Should there be a libzend-framework-zendx-php dummy package that depends on something else in the new set? [17:10] slangasek: right, i could do that, but there's nothing that is libzend-framework-zendx-php that is provied by zendframework, unfortunately [17:11] slangasek: so the zend-framework orig tarball differs from zendframework. z-f used the 'full' tarball which included unsupported/experimental extensions, zf only ships the core [17:12] slangasek: and so zf doesn't provide those extensions at all, or anything that replaces that functionality [17:13] nacc: ok. In that case, the current packages are probably fine as-is and we just need to mangle the archive a bit to let this in [17:15] slangasek: ack, I wasn't finding anything in the debian manual that covered this case -- and the upgrade of the packages that are upgradeable does work (i tested that already earlier) -- it's just this one leaf package. [17:18] So, now that the word is out about the apt security update: I also uploaded 1.2.18 to xenial-proposed to replace the 1.2.17 in the queue there, so the queue contaisn a fixed version too [17:19] To prevent an accidental upload of 1.2.17, it would be wise to remove it from the unapproved queue, and only keep 1.2.18 in there [17:19] s/upload/approval/ === scottt is now known as Guest87990 [17:25] That said, I might want to rebuild the changes file for 1.2.18 with all changes since 1.2.15 [17:41] juliank: Yeah, can you reupload 1.2.18 with the right -v? [17:43] infinity: done [17:43] juliank: Ta. [17:46] Now I need to figure out when the next normal stable release updates will happen. My queues got a bit strange with the whole security business [17:46] s/queues/patch queues/ [17:47] doko: For some reason libaws has built now, so maybe this ada stuff can move forward a bit [17:47] That is, 1.3.3 and 1.2.19 will happen at some point. Not sure when, though. [17:47] * Laney is off from today but might poke at it a bit if there's time [17:47] otherwise please do [17:49] * juliank is a constant bugfix cherry-picking machine [17:56] juliank: Why did aclocal.m4 and configure disappear? [17:56] infinity: What, that sounds weird. [17:56] juliank: (I realise they probably come back on debian/rules clean, but that still seems like poor form for an upstream tarball to not ship them) [17:57] Ah [17:57] Right [17:57] infinity: I accidentally passed -nc to gbp buildpackage. [17:57] I'll reupload one without -nc [17:58] Too many non-git uploads prepared the past week [17:58] juliank: Ta. I assume 1.2.18 doesn't actually "exist" in the wild outside of the xenial queue? [17:58] Not in the tarball form :) [17:58] Check. [17:58] Then a fresh upload would be lovely. [17:59] debian/copyright went byebye too. Symptom of the same oops? [17:59] infinity: Should be in now. [18:03] juliank: That looks better. Will give it a bit of a once-over for obvious breakage and accept today. [18:03] neat [18:04] This will make sarnold very happy :) [18:04] He's never happy. [18:13] :) [18:14] he smiled! [18:14] It's a ruse. [18:18] hi, would anyone be able to sponsor a xenial sru for bubblewrap? https://bugs.launchpad.net/ubuntu/+source/bubblewrap/+bug/1649330 [18:18] Launchpad bug 1649330 in bubblewrap (Ubuntu) "[SRU] bubblewrap unavailable on xenial" [Undecided,New] [18:21] juliank: Unrelated to the quality of the SRU (which I'm about to accept), but I suspect your travis.yml referencing wily all over the place might explode when we remove wily from the mirrors. [18:22] attente: In any case, the version number is wrong. Not sure about policy regarding adding new packages in an SRU. [18:22] infinity: Yeah. I'm building a PPA picking the components I need, but I'm not done yet [18:23] juliank: what should the version number be? [18:23] attente: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging [18:23] is a good reference [18:24] nacc: thanks [18:24] i'll update that [18:24] nacc: That does not mention anything about those ~ uploads though [18:25] juliank: you mean, e.g. ~ppa1 etc? [18:25] nacc: I meant, you basically would want 0.1.4-2~ubuntu0.1 [18:25] otherwise your version is higher than zesty [18:26] zesty having 0.1.4-2 [18:26] attente: Two things. Version should be "0.1.4-2~16.04.1" to indicate a no-change backport. [18:26] attente: Second thing: can you see if 0.1.2-1 from yakkety works just as well for your purposes? [18:27] attente: Cause xenial should *not* be higher than yakkety, so if you *need* the zesty verion, then it needs to be backported to both releases, with a really good reason why. [18:27] juliank: ah yes, i hadn't looked at the details of this specific case [18:27] infinity: d'oh, of course [18:27] attente: (note: I'll probably reject that reason unless it's stellar) [18:27] attente: So, preferably, backport yakkety's version, so if it does the job, then let's do that. [18:27] s/so if/see if/ [18:28] infinity: thanks, i'll do that [18:28] attente: Basic reasoning here from my side: There's pretty much 0 chance of regression in introducing a NEW package into an old release, but updating a package in a stable release is much more potentially dangerous. [18:28] So, happy to handwave review and accept the yakkety version backported to xenial, once you verify it fits your needs. [18:29] infinity: thank you [18:31] slangasek: infinity: do i also need AA help for the imagemagick migration? (two binaries being removed in the version change) [18:31] nacc: Usually not. [18:32] nacc: Binary removal is simulated by proposed-migration to do the installability checks, but they're not actually removed until after migration, when we get around to tidying up after you. [18:32] nacc: Oh. Except for those two NBS binaries that are *in proposed*. I'll whack those. [18:33] infinity: ah thanks! [18:34] nacc: Cleaned up for you. [18:40] infinity: thanks again! [18:51] infinity: hi, i've tried the yakkety version and it works fine too. the version is also fixed: https://launchpad.net/~attente/+archive/ubuntu/test?field.series_filter=xenial [18:55] nacc: yeah, when you see those kinds of messages in update_excuses, pointing the AAs at it is the right thing to do [19:47] slangasek: thanks! === salem_ is now known as _salem [22:40] Any ipmitool maintainers around? [23:19]