=== mwsb is now known as chu
[00:50] <Unit193> So after the apport retracer runs, isn't it supposed to remove private data and make a private bug public?
[00:50] <sarnold> mostly yes
[00:51] <Unit193> https://bugs.launchpad.net/ubuntu/+source/variety there's a lot of recent bugs here that have been processed by apport, but are private.
[00:54] <sarnold> curious. I can see them even though I thought I didn't have privileges to see "private" bugs, only "private security" bugs.
[00:57] <Unit193> I have a little because of being Xubuntu dev.  A Debian developer maintains that package, and while not using Ubuntu he actually does try to keep on top of things.
[00:58] <tsimonq2> Unit193: I can see those bugs, for what it's worth.
[00:58] <tsimonq2> (I'm a member of the relevant Apport something or other team, something Brian Murray owns :P)
[00:59] <Unit193> tsimonq2: That really doesn't help.  The question was: "Why doesn't apport set these public?"
[00:59] <tsimonq2> Unit193: Well that's because the stacktraces "could" "possibly" have sensitive information.
[01:00] <tsimonq2> Unit193: As far as I can tell, Apport does that for *, right?
[01:00] <Unit193> It's supposed to review, debug a little, remove private, set public.  At least as far as I know.
[01:01] <tsimonq2> I suspect that bdmurray might know the answer to that question.
[01:01] <tsimonq2> I don't think it did it automagically, did it?
[01:01] <Unit193> I have seen it do so in the past.
[01:02] <tsimonq2> Oh? Got a bug number? I'm curious what it spits at the bug.
[01:04] <Unit193> Not offhand.
[01:05] <tsimonq2> Alright, that's fine, but if you happen to come across one, let me know.
[01:05] <Unit193> tsimonq2: Though if you get bored and go through all of them before I do, that'd work too. :P
[01:06] <tsimonq2> Unit193: Heh. I've been keeping myself busy enough lately :)
[01:41] <bdmurray> Unit193: No apport is not supposed to the set the bug to public. It doesn't have the smarts to tell if there is sensitive data or not so that requires manual review.
[01:41] <tsimonq2> Oh. Makes sense.
[01:42] <sarnold> hrm. I thought I'd seen it open some bugs up.
[01:42] <Unit193> ↑
=== Laney is now known as Guest19654
=== infinity0_ is now known as infinity0
=== JanC_ is now known as JanC
[07:12] <blahdeblah> Flannel, hggdh, Tm_T, Unit193: Are any of you ops in this channel & #ubuntu?  In the next hour or so I'm going to send an email about a brief service-affecting outage on Sunday at 23:00 UTC, and want to make sure we'll have someone who can op us briefly, or update topics for us.
[07:13] <Flannel> Service outage for what?
[07:14] <blahdeblah> Various web sites, incl. Launchpad git, ubuntu.com, canonical.com, etc.
[07:14] <Flannel> Regardless, yes, we have people who can update topics.  Although I may not personally be around.
[07:15] <blahdeblah> Who's the best person to ask at that time of the week?
[07:15] <Flannel> blahdeblah: Go to #ubuntu-ops and let them know, and then topics will get updated.  That's the place.  Or #ubuntu-irc, but -ops is probably better.
[07:15] <blahdeblah> thanks
[07:45] <niedbalski> rbasak, ping
[07:52] <niedbalski> tjaalton, rbasak could you please check the SRU for LP: #1657256? thank you.
[07:52] <ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.6 (Ubuntu Zesty) "Percona crashes when doing a a 'larger' update" [High,In progress] https://launchpad.net/bugs/1657256
[08:01] <tjaalton> niedbalski: I'm about to EOW to start moving my office and everything after a 5mo evacuation, and this bug seems to be a tough one to go through with little time
[08:05] <niedbalski> tjaalton, gotcha, fyi it's already in unapproved.
[08:06] <tjaalton> noticed, still needs sru review
=== JanC_ is now known as JanC
[09:49] <cpaelzer> xnox: hiho - is there an override for systemd dep8 test on zesty already?
[09:49] <cpaelzer> xnox: http://autopkgtest.ubuntu.com/packages/s/systemd/zesty/armhf looks rather consistently red
[09:51] <xnox> cpaelzer, i'm not going to give you a straigh answer =)))))))) is there a "regression systemd/armhf" mentioned on a pending_sru page for you?
[09:51] <xnox> cpaelzer, have you looked at the britney override hints for zesty?
[09:51] <xnox> cpaelzer, do you know where to look both of those things up
[09:51] <xnox> ?
[09:52] <xnox> test-copy is known to fail, because test-copy binary is compiled too small and it is used as part of test suite. I am hoping to cherrypick test fix for that, and get systemd to become green.
[09:52] <xnox> and there is a hint committed into zesty series of britney hints in the bzr branch by ~ubuntu-sru
[10:01] <doko> mitya57: could you merge qtbase-opensource-src ?
[10:20] <cpaelzer> xnox: I saw it in an pending-sru
[10:20] <cpaelzer> xnox: and honestly I don't know if the overrides would make it not show up there or not
[10:20] <cpaelzer> xnox: and I have to admit I didn't check the overrides yet, but I can
[10:23] <cpaelzer> thanks for the answer
[10:25] <cpaelzer> I didn't know there is a ubunut-sru branch of the hints
[10:25] <cpaelzer> xnox: I beg your pardon but can you send me a pointer for that that is better than https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu ?
[10:25] <cpaelzer> found it I think
[10:25] <cpaelzer> all in https://code.launchpad.net/~ubuntu-sru
[10:27] <cpaelzer> ok found all of them, learned about the per-release nature of the overrides now
[10:27]  * cpaelzer ticks the "learned something today" checkbox :-)
[10:46] <rbasak> Does udev definitely continue a RUN+= sequence if a script returns non-zero? I can't find the behaviour defined anywhere.
[10:49] <rbasak> I mistake; I don't think it matters here. Though I'm still curious to know the answer.
[10:58] <xnox> cpaelzer, however, it really should be hinted over =/
[10:58] <xnox> cpaelzer, let me double check the report
[11:00] <xnox> cpaelzer, ah! it is hinted, but needs more hinting due to security update.
=== sil2100 changed the topic of #ubuntu-devel to: Artful Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
[11:04] <xnox> cpaelzer, https://code.launchpad.net/~xnox/britney/hints-ubuntu-zesty/+merge/332899 should make you happy, once merged.
[11:10] <cpaelzer> xnox: thanks
[11:10] <xnox> juliank, http://paste.ubuntu.com/25829628/ -> glob, regex, but why no relative full filename?
[11:11] <xnox> juliank, had to do this # sudo apt install `find . -name '*.deb'`
[11:11] <juliank> xnox: Needs to start with ./
[11:11] <juliank> xnox: The reason is to make it easy to differentiate from real package names.
[11:11] <xnox> juliank, not user friendly as there is no bash shell expansion for ./*.deb
[11:11] <juliank> So, apt install ./*.deb would have worked
[11:12] <xnox> juliank, but if there are no real package name.... it already tried glob and regex which are not real package names either.
[11:12] <juliank> xnox: That expands normally
[11:12] <xnox> trying by filename is sane.
[11:13] <xnox> juliank, hm, ./*.deb does work, but this is the first time in my life that do such an expansion =)
[11:13] <Faux> Never had a file named -? :)
[11:14] <juliank> xnox: The autocompletion also only expands ./, I'd love to teach it to automatically turn filenames without it into that format. I don't like it either, but we really need to figure out things in general with command-line.
[11:14] <xnox> Faux, i opened nautilus to remove that one!
[11:14] <juliank> We just fixed Debian porterboxes dd-schroot-cmd to not accept package names starting with ./ or / in order to prevent people from installing locally built packages and gain root privileges.
[11:15] <xnox> juliank, hahahahahaha
[11:15] <xnox> cute
[11:16] <juliank> The regex and glob thing should go away eventually, it's really unpredictable.
[11:17] <juliank> Like, apt install foo1.2 -> installs foo1.2 if foo1.2 exists, otherwise installs anything matching regex foo1.2
[11:17] <juliank> So I think long term we probably have package names, files, ? patterns, and ~ patterns
[11:18] <juliank> And I guess ?file(path) or something
[11:19] <juliank> aptitude's handling is OK, my goal is to get closer to that.
[11:19] <juliank> xnox: I guess we should at least make apt check if the specified argument is an existing file, and then say: Please prepend ./
[11:20] <xnox> juliank, yes
[11:20] <xnox> it should check that the specified argument is an existing file, and say this is ambigious
[11:23] <juliank> xnox: I guess one case where just respect any file name would break down is if you have a directory pkg with an extracted pkg, and do apt-get build-dep pkg and it's completely unclear if you mean the real package or the directory :)
[11:25] <xnox> juliank, check that a file foo_18241-1_arch.deb exists, not a foo_18241-1_arch.deb folder =)
[11:25] <juliank> build-dep can actually take both files and directories as arguments
[11:25] <xnox> juliank, oh that works, hm i always did $ apt build-dep ./
[11:26] <xnox> juliank, and imho it should actually just be $ apt build-dep
[11:26] <xnox> juliank, and it should require to be in the top of the unpacked package
[11:26] <xnox> juliank, just like the rest of ./debian/rules
[11:26] <juliank> I'd like apt install ?build-depends(package) ?build-depends-file(...) ?build-depends-dir(...) or something
[11:27] <xnox> juliank, nobody apart from you will remember that
[11:27] <xnox> define an order and print a warning, if a particular order is used, but is ambigious.
[11:28] <xnox> file/dir overriding pkg with a warning when specified without ./ is sane
[11:28] <juliank> xnox: That's probably true. But apt-get build-dep could translate to that. And it gives you the ability to tweak build-dep installation, so you could manually specify an alternative
[11:28] <xnox> what is build-depends-file? is that .dsc or debian/control?
[11:29] <juliank> Well, that's really the same from our perspective IIRC
[11:29] <xnox> my undertanding was that specifying dir, is actually translating dir -> dir/debian/control
[11:29] <juliank> yeah
[11:29] <juliank> I think so
[11:29] <xnox> hence there is no build-depends-dir
[11:29] <xnox> (underlying, it's syntatic sugar)
[11:30] <juliank> right
[11:30] <xnox> and when i do $ apt build-dep foo_1-1.dsc -> i do mean the file here locally, not the package name
[11:31] <juliank> Anyhow, my plan is to sit down in January and define a proper pattern/package specification language and then implement that, starting with apt(8) and warning about incompatible uses in apt-get(8) for some time before switching that over
[11:31] <xnox> imho you should ignore regex/glob/pkg-name if the argument ends with .dsc .deb /control
[11:31] <xnox> and use file:/// syntax if something ends in .dsc .deb /control
[11:32] <xnox> and declare that package names ending in '.dsc .deb /control' are broken.
[11:32] <juliank> Let's just support all URIs :D
[11:32] <juliank> apt install https://host/path/to/deb
[11:32] <xnox> juliank, why not recursive glog too? $ apt install https://host/path/to/archive/*
[11:32]  * xnox giggles =)
[11:33] <juliank> xnox: /control might in fact be a valid release specifier like apt/xenial
[11:33] <xnox> juliank, apt-url is built-in to fetch all the things, right right
[11:33] <xnox> juliank, sigh
[11:34] <juliank> xnox: It's at least not an adjective, so it won't be the next release codename :)
[11:34] <xnox> juliank, warning + use local if ends in "/control .dsc .deb" is sane and say something like "use apt --no-file debian/control, if you mean to install a package called debian from a component called control"
[11:34] <xnox> component? the term is suite, no?
[11:35]  * xnox always confuses those things
[11:35] <juliank> It's not component.
[11:35] <juliank> APT calls it archive or codename, depending on what it is, but others might use suite or release or something
[11:36] <juliank> In fact, APT has APT::Default-Release, so it also calls it release.
[11:36] <xnox> ok so i'm not crazy for not knowing the term for the thing
[11:36] <juliank> apt-get(8) calls it distribution
[11:37] <juliank> xnox: The other thing also has different names, component, section, probably more.
[11:38] <juliank> section (main) could easily be confused with section (admin), though
[11:50] <juliank> oh, apt and python-apt are basically in an autopkgtest cycle.
[11:51] <juliank> python-apt tests against apt 1.5 which fails, and apt 1.5 tests against old python-apt which fails too :)
[11:52] <juliank> But I see some retries with newer versions, so at least its working there
[11:53] <juliank> apt has test depends on python3-apt for one specific test case...
=== freyes__ is now known as freyes
[16:16] <jbicha> infinity: are you ok with me adding my patch from https://bugs.debian.org/879157 to bionic?
[16:16] <ubottu> Debian bug 879157 in vim-common "vim-common: Set NoDisplay=true for vim.desktop" [Normal,Open]
[16:21] <infinity> jbicha: Unsure.  I'm generally not a fan of terminal apps showing in GUI menus, but vim and emacs are sort of special snowflakes, being the preferred editors of most Linux users, despite being terminal apps.
[16:23] <infinity> jbicha: And it works so seamlessly at least in GNOME (opens in my default terminal, with my preferred terminal size, etc) that it may as well be a GUI app.
[16:23] <infinity> Heck, it feels more integrated than gvim. :P
[16:23] <rbasak> gvim isn't bad as a GUI app.
[16:23] <rbasak> At least unsuspecting users will be able to leave :)
[16:23] <infinity> You can leave just by closing the terminal.
[16:24] <rbasak> Doesn't that give you a scary warning?
[16:24] <infinity> Nope.  Try it.
[16:24] <infinity> Windows key -> vim -> enter -> close.
[16:24] <rbasak> Interesting. I wonder how it manages that.
[16:25] <rbasak> Oh
[16:25] <rbasak> It just closes even if I make changes.
[16:25] <infinity> Well, yes.
[16:25] <rbasak> I stand by my claim then. gvim is better integrated :)
[16:26] <infinity> I dunno.  I could go either way.
[16:26] <jbicha> I believe GNOME is the most used desktop on Debian and it's hidden there…
[16:27] <infinity> Yeah.
[16:27] <rbasak> GNOME would :)
[16:27] <jbicha> I did try to upstream it but I haven't had luck so far
[16:27] <infinity> jbicha: I'll probably take this patch in.  I'd prefer to upload myself, so I don't lose track of TIL for merges.
[16:27] <jbicha> ok, thanks!
[16:29] <jbicha> my strategy to get it upstream now is to try to get distros to take my patch before asking upstream again
[16:30] <infinity> jbicha: Yes, their justification for closing it was "both show up on Ubuntu and that's fine", which is a bit lolz, given you're from Ubuntu. :)
[16:31] <infinity> jbicha: Oh, wait.  I was under the impression that this was a "new" feature.  We've been shipping this for years?
[16:31] <infinity> Hrm.
[16:31] <infinity> Now I'm less okay with removing it.
[16:31] <infinity> Cause uers might actually be used to it being there in their workflow.
[16:32] <jbicha> oh Fedora actually doesn't ship vim.desktop at all
[16:33] <infinity> That could be a packaging bug rather than intentional.
[16:33] <jbicha> the GNOME Activities Overview makes .desktops a lot more prominent than in Unity so it's more annoying now
[16:33] <infinity> (ie: when it was added upstream, they may have just not noticed)
[16:33] <jbicha> https://src.fedoraproject.org/rpms/vim/blob/master/f/vim.spec#_1205
[16:34] <infinity> Intentional indeed.
[16:35] <infinity> That is one ugly specfile.
[17:02] <infinity> jbicha: While I'm waffling on this vim.desktop thing, do you... Oh look, you already fixed mozjs38, NEVERMIND.
[17:02] <infinity> Well, "fixed".
[17:02] <infinity> By skipping tests.
[17:02] <infinity> Ick.
[17:02] <jbicha> best fix
[17:03] <jbicha> it's Cinnamon's fault that we still have mozjs38 in Ubuntu
[17:03] <slangasek> bdmurray, jbicha, cyphermox, micahg, rbasak, sil2100: https://bugs.launchpad.net/bugs/1716770 is in the DMB's hands now regarding population of the ppu packageset, correct?
[17:03] <ubottu> Launchpad bug 1716770 in ubuntu-community "[TB/DMB] New packageset ~personal-fossfreedom in Artful" [Undecided,New]
[17:04] <jbicha> infinity: I did try applying https://github.com/mozilla/gecko-dev/commit/526416 but it's got RTL stuff going on and it didn't seem to work
[17:05] <infinity> jbicha: Neat.
[17:05] <infinity> jbicha: Though, that also seems to imply that it's just the test that sucks, and not the code being tested, so a bit more blase about the test being skipped.
[17:07] <jbicha> infinity: you might like LP: #1728038 once edbrowse and libproxy publish and so on
[17:07] <ubottu> Launchpad bug 1728038 in oolite (Ubuntu) "Remove ancient mozjs from bionic" [Undecided,New] https://launchpad.net/bugs/1728038
[17:07] <cyphermox> slangasek: looks that way, yes
[17:09] <sil2100> slangasek: I guess yes, thanks! We'll try to finally resolve the budgie packageset in our nearest meetings
[17:09] <slangasek> sil2100: ok; but this is fossfreedom's ppu, so that is not blocked on that meeting, correct?  you have a list of packages ready to be added to that acl?
[17:10] <slangasek> I would offer to jfdi this part, but last I knew I could create a packageset owned by the dmb but not add things to that packageset ;)
[17:11] <sil2100> slangasek: let me do that now ;)
[17:11] <slangasek> cool, thanks
[17:23] <sil2100> fossfreedom: you have now been granted your rights for bionic, use this power wisely!
[17:24] <jbicha> it looks like some s390x builders don't have bionic-proposed enabled? https://launchpad.net/ubuntu/+source/gnome-maps/3.26.1-1/+build/13629162
[17:24] <cjwatson> that's not done on a per-builder basis
[17:25] <cjwatson> that build was attempted in the release pocket, because it was on an arch that previously failed in artful, so was retried in bionic after being copied forward
[17:26] <cjwatson> it'll be automatically retried once the new gjs makes it to bionic from -proposed
[17:26] <jbicha> that's unexpected but ok
[17:30] <cjwatson> it sort of makes sense, and since that kind of thing almost always only clears when dep-waits become available, it usually works out
[17:32] <infinity> cjwatson: Speaking of add-missing-builds, is there still a backlog work item and/or bug somewhere to have that functionality rolled into series init?
[17:32] <infinity> cjwatson: It's one of the few remaining reasons for ftpmaster shell.
=== ahasenack is now known as andreas
[18:28] <cjwatson> infinity: I don't think so ...
[18:38] <infinity> Oh, lovely, icu59 forces c++11/gnu++11.  Derp.
[18:40] <infinity> Do I turn icu into ifdef hell and submit upstream, or make the 2 C++ projects that fail use C++11?  Decisions, decisions.
[18:44] <sarnold> are those two C++ projects C++14 or C++bad?
[18:44] <infinity> sarnold: The latter.
[18:44] <infinity> And oh my, just switching from gnu++98 to gnu++11 makes this thing explode SPECTACULARLY.
[18:45] <infinity> So maybe doing the correct icu ifdef fix is smarter.
[18:45] <infinity> (icu seems to have not noticed that they made their headers dependent on a C++ type that only appeared in C++11)
[18:45] <sarnold> infinity: do we -need- those packages? :)
[18:46] <infinity> sarnold: I mean, that's potentially up for debate, but it's still poor form to make a pretty core system library suddenly demand its rdeps use a certain language standard.
[18:46] <infinity> Oh, I might be able to work around this with a -D
[18:47] <sarnold> infinity: and yet I can entirely understand why someone would want to use C++11
[18:49] <infinity> sarnold: Sure, but 6 years isn't actually a long time to expect the long tail to catch up.
[18:49] <infinity> (sadly)
[18:49] <sarnold> infinity: right
[18:50] <infinity> sarnold: Using 11, or even 14 in your shiny leaf node application is awesome and encouraged, in a low level system library used by hundreds of consumers, a bit of guarding isn't too much to ask.
[18:50] <infinity> Or maybe I live in a fantasy world.
[18:50] <sarnold> infinity: just how much work is the ifdef hell? that might (a) already be done by someone else in their issue tracker (b) if not, would probably be something someone else would love to find stuffed in the icu issue tracker
[18:51] <infinity> (Or, rather, using it in your low level library is also great, but exposing that through your ABI/API isn't)
[18:51] <infinity> sarnold: Dunno, I'm trying to sort out if it might actually end up part of the ABI.  It might.  In which case, one can't fix this in headers, one would have to make a build-time choice, which sucks a bit.
[18:57] <infinity> Well, my hack worked, so my carefactor just lowered a bit.
[18:57] <sarnold> yay!
[19:10] <geofft> anyone want to sponsor my SRU? it's a small fix, it's in universe, and it comes with autopkgtests :) LP #1725110
[19:10] <ubottu> Launchpad bug 1725110 in config-package-dev (Ubuntu Artful) "config-package-dev 5.2 broke transforms" [Undecided,Confirmed] https://launchpad.net/bugs/1725110
[19:10] <geofft> or is there a better place for me to ask for sponsorship? (#ubuntu-motu maybe?)
[19:13] <nacc> geofft: looking
[19:15] <nacc> geofft: so, iiuc, bionnic will auto get the fix when 5.4 syncs?
[19:15] <geofft> yes
[19:15] <geofft> I fixed it in Debian as soon as I got the bug report, that was just after artful's Debian import freeze
[19:16] <nacc> geofft: ok, so I do't think i'd sponsor the 17.10 change, i'd just sync it (ow that the archive is open)
[19:17] <geofft> so if an SRU that takes the form of syncing from Debian is a thing that can be done, that works. (or if the answer is "wait a bit for bionic then come back" that works for me)
[19:17] <nacc> geofft: sorry, i meant that bionic needs the fix first
[19:17] <nacc> geofft: and the right way for bionic to get the fix is to sync from debian
[19:18] <geofft> do I need to do anything for that to happen? it's not patched currently so it should get auto-synced, right?
[19:18] <nacc> geofft: yeah, i'm assuming the sync job is prety loaded right now, it might just not have hit it yet
[19:19] <geofft> cool, I'll check back in a couple of days, thanks!
[19:20] <geofft> nacc: at that point is the right thing to request sponsorship of the 5.4~ubuntu17.10.1 debdiff already on the bug, or do something else for the SRU?
[19:22] <jbicha> nacc: autosync hasn't been turned on yet, but you're welcome to manually sync packages
[19:25] <nacc> jbicha: ack, i know :)
[19:26] <nacc> geofft: i don't think a full version update is immediately appropriate for an SRU
[19:26] <nacc> geofft: i'm readingn the bug still, though
[19:29] <nacc> geofft: meanwhile, I can sync it for bionic, at least
[19:29] <geofft> thanks!
[19:30] <nacc> geofft: would it be possible to list functional changes between 5.2 and 5.4 and why it is safe for SRU? it might be in there, but i'm having a bit of trouble parsing it out
[19:31] <geofft> the only functional change is the bugfix. the other changes are autopkgtests, fixing examples/ so that autopkgtest works, adding .travis.yml and README.md (irrelevant for the package), and updating standards-version
[19:32] <geofft> because I was not previously testing the examples, they were badly out of date :-(
[19:32] <nacc> geofft: ah ok
[19:32] <geofft> so it looks noisy
[19:32] <nacc> geofft: right, i think that was the concern :)
[19:32] <nacc> geofft: i also think we'll need to fiddle the versioning for 17.10
[19:33] <nacc> geofft: oh nm, you used ~
[19:33] <nacc> geofft: i do thnnk it might be missing an `update-maintainer`?
[19:36] <geofft> woops, yes. sorry, I haven't done Ubuntu dev in forever :(
[19:36] <nacc> geofft: np, i can run it locally, just easier to tick stuff off while i have you on irc :)
[19:48] <nacc> geofft: https://launchpad.net/ubuntu/+source/config-package-dev/5.4
[19:52] <geofft> nacc: nice, thanks!
[19:54] <geofft> nacc: I ran update-maintainer and uploaded a new debdiff
[19:54] <nacc> geofft: thank you
[19:59] <infinity> geofft: FWIW, you could have asked someone to sync this into artful before release.  The Debian import freeze is a freeze on automatic imports, but manual syncs for bugfixes are much appreciated.
[19:59] <infinity> (but indeed too late now, and yay SRU)
[20:00] <geofft> infinity: yeah, I just completely failed to notice :(
[20:01] <infinity> geofft: Life will probably somehow go on. :)
[20:02] <karstensrage> hey infinity hope things are well, any chance we can revisit my packages?
[20:02] <infinity> karstensrage: Oh crap.  Speaking of forgetting things.
[20:02] <infinity> karstensrage: Yes, we absolutely ca.
[20:02] <infinity> n
[20:02] <karstensrage> i know you were busy with personal things
[20:02] <karstensrage> so i havent wanted to bother you
[20:02] <infinity> That was kind.
[20:04] <karstensrage> so if you recall there was update to a package that already exists, so like a new version of upstream
[20:05] <karstensrage> and there is going to be a new package that depends on it
[20:06] <infinity> I have a feeling this webkit build might test the limits of my "build everything in RAM" strategy...
[20:06] <infinity> karstensrage: Yep, an NSS module and a PAM module, IIRC.
[20:19] <tsimonq2> infinity: How many builds does the arm builder build before the arm builder needs rebuilding?
[20:19] <tsimonq2> *ahem*
[20:19] <tsimonq2> I mean
[20:19] <tsimonq2> What's up with arm builders? :)
[20:20] <infinity> tsimonq2: Other than "they're a little over capacity right now"?
[20:22] <tsimonq2> infinity: Why are they over capacity while the others are fine?
[20:23] <infinity> tsimonq2: Because we don't have precisely identical capacity on all arches.
[20:23] <infinity> (I feel like that's an obvious answer...)
[20:23] <tsimonq2> infinity: My point is, ppc64el is fine and it only has 30 builders...
[20:23]  * tsimonq2 shrugs
[20:23] <tsimonq2> Maybe I'm missing something obvious.
[20:23] <infinity> tsimonq2: 30 much faster builders.
[20:24] <tsimonq2> Ah, gotcha.
[20:24] <infinity> tsimonq2: Also, ppc64el only builds one arch, arm64 builds two.
[20:24] <infinity> (arm64 and armhf)
[20:24] <Unit193> ppc64el builders always seem to finish first, armhf tends to be last.  From what I've noticed.
[20:24] <infinity> It's a game of leapfrog.
[20:24] <tsimonq2> infinity: Interesting.
[20:24] <infinity> For a couple of years, armhf was always the first done.
[20:25] <infinity> Then we built up capacity elsewhere.
[20:25] <infinity> Lather, rinse, repeat.
[20:25] <tsimonq2> So then I wonder why we don't have more arm builders.
[20:25]  * tsimonq2 shrugs
[20:25] <infinity> See above, re: game of leapfrog.
[20:25] <tsimonq2> I'm just asking because it's being a bottleneck.
[20:25] <tsimonq2> Oh.
[20:25] <infinity> In an ideal world, I'd put in a PO for a few hundred of every machine and never run out of capacity, but it's not an ideal world, and I'd prefer not to get fired for being a twit.
[20:26] <tsimonq2> Heh.
=== JanC_ is now known as JanC
[20:36] <cjwatson> tsimonq2: One major reason is that server-class arm64 hardware has been a bit of a movable feast.  The generation we're using at the moment is really the first we have that's actually been server-class (not devboards, virtualisation-capable, etc.), but unfortunately it's no longer being manufactured and we haven't worked out what the next one along is going to be.
[20:39] <cjwatson> tsimonq2: So at this point it isn't so much just a matter of "buy more of the same and plug it in" (when we heard it was going EOL, we bought up pretty much all we could ...), as "decide on a new platform, qualify OpenStack on it, etc.".
[20:39] <cjwatson> tsimonq2: It's likely to be more interesting still because the hardware we have supports ARMv7 insns natively, which is nice for armhf build performance, but isn't actually required by the ARMv8 architecture.
[20:40] <cjwatson> tsimonq2: So we'll have to be quite careful with the next generation of hardware to make sure armhf still builds reasonably.
[20:40] <infinity> cjwatson: To the last point, most manufacturers are still opting into that, if we just avoid the ones that don't.
[20:40] <cjwatson> (whatever that generation may be ...)
[20:40] <infinity> My bet's on QC being a good possibility for next gen.
[20:40] <cjwatson> infinity: Right, it's just another way to limit the field
[20:50] <juliank> jbicha: We need to stop requesting new python-apt autopkgtest runs, there are 3 or 4 in the queue now. so wasteful...
[20:50] <juliank> python-apt {"triggers": ["python-apt/1.4.0~beta3ubuntu1", "apt/1.5.1"]}
[20:50] <juliank> python-apt {"requester": "jbicha", "triggers": ["apt/1.5.1", "python-apt/1.4.0~beta3ubuntu1"]}
[20:51] <juliank> python-apt {"requester": "costamagnagianfranco", "triggers": ["apt/1.5.1", "sphinx/1.6.5-1"]}
[20:51] <juliank> and
[20:51] <juliank> python-apt {"requester": "juliank", "triggers": ["apt/1.5.1", "python-apt/1.4.0~beta3ubuntu1"]}
[20:51] <juliank> oh man
[20:51] <juliank> jbicha: Sorry, forgot :D
[20:51] <juliank> * a :D
[20:51] <jbicha> at least we only did one each, right?
[20:52] <juliank> yeah
[20:52] <jbicha> at least it's not one of the longer autopktests to run http://autopkgtest.ubuntu.com/packages/p/python-apt/bionic/amd64
[20:54] <juliank> yeah
[20:54] <juliank> I wonder what's happening with snapcraft on armhf
[20:56] <juliank> with different errors even
[20:57] <tsimonq2> cjwatson: Huh, interesting. Good to know.
[21:03] <LocutusOfBorg> juliank, sorry, I triggered them on batch, because of armhf failures due to ENOSP
[21:03] <LocutusOfBorg> they weren't "intentional"
[21:08] <infinity> juliank: The one with no requestor was me.  The rest are all from terrible people. :)
[21:09] <juliank> infinity: yeah
[23:35]  * jbicha grumbles at qtdeclarative-opensource-src