[01:46] <smoser> hey. just wondering.
[01:46] <smoser> I had the idea that our team could get a jump on testing of -proposed by uploading to a PPA exactly what we uploaded to -proposed
[01:47] <smoser> then we could test that before an SRU team member reviewed and let into -proposed.
[01:47] <smoser> I tried that, but
[01:47] <smoser> Uploads aren't permitted to pocket: proposed
[01:49] <smoser> i guess thats easily fixable by not setting the release to 'xenial-proposed' in our changelog.
[02:24] <TJ-> I seem to have found a package-install failure on upgrade on bionic for libc6-{,dev-}armhf-cross, reported it in comment #32 of Bug #1769657
[02:34] <sarnold> TJ-: anything in dmesg or auditd logs?
[02:37] <TJ-> sarnold: not found anything, no.
[02:39] <sarnold> TJ-: thanks for looking. I didn't see any problems with installing these brand-new, so I wondered if it was something more specific to your system..
[02:42] <TJ-> sarnold: yeah, I've tried several times in different ways (apt --reinstall  vs dpkg -i) and the same issue occurs. I've re-fetched the .debs in case of corruption too
[02:43] <TJ-> sarnold: I guess I should strace it
[02:44] <sarnold> how about debsums -a libc6-armhf-cross libc6-dev-armhf-cross  ?
[02:52] <TJ-> sarnold: reports !=   because the installed files are the previous package still
[03:01] <TJ-> the strace looks weird; the various hf -> libhf directory names and symlinking make it confusing but it seems like it is unlink-ing the file then wondering where it has gone!
[06:31] <alkisg> Hi, `apt install` in 18.04 deletes e.g. "/var/cache/apt/archives/sl_3.03-17build2_amd64.deb" right after `apt install sl`. That would be a bug and not a design choice, right?
[06:31] <alkisg> I.e. it autocleans all downloaded debs right after their installation. I think it didn't do that a few months ago, so it must be a recent issue...
[06:33] <alkisg> Example: apt purge sl; apt clean; strace -fe trace=file apt install sl 2>&1 | tail; ls /var/cache/apt/archives/
[06:33] <alkisg> ==> unlink("/var/cache/apt/archives/sl_3.03-17build2_amd64.deb") = 0
[08:47] <rbasak> infinity: you might be interested in bug 1795919. glibc is implicated. Do you happen to know of any changes in this area?
[08:56] <infinity> rbasak: Not sure I see much implication there, based on the mailing list post's "science". :P
[08:56] <rbasak> infinity: I thought it was "glibc upgrade triggers the bug with nothing else changed"?
[08:57] <infinity> rbasak: No, it was "I recompiled it on a machine with glibc 2.24", which really doesn't tell me at all what he changed.
[08:57] <infinity> rbasak: The implication of "machine with glibc 2.24" is "everything there is older and different".
[08:57] <infinity> rbasak: Yes, he's right that the header changed, https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=4d728087ef8cc826b05bd21d0c74d4eca9b1a27d
[08:58] <infinity> rbasak: But that should have been something vaguely close to a no-op.  And if it wasn't, it's a kernel bug.
[08:58] <infinity> (ie: glibc has stopped (re)defining kernel stuff, and glibc has nothing to do with quotas)
[08:59] <rbasak> Perhaps dovecot is "uncalculating" the size based on the wrong block size?
[09:11] <infinity> rbasak: Simple reproducer welcome? :P
[09:13] <infinity> rbasak: Worth noting that 2775445504 (reported by dovecot) /1024 is exactly 2710396 (reported by repquota)
[09:30] <rbasak> tdaitx: are you waiting for something on https://code.launchpad.net/~tdaitx/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/355346? We don't have automatic sponsorship as part of the process; if you need sponsorship you'll need to find a sponsor out of band.
[13:01] <coreycb> tjaalton: hi, any chance you could take a look at neutron in the bionic unapproved queue during your sru rota today? it has some critical bug fixes.
[13:09] <tjaalton> coreycb: on it
[14:00] <coreycb> great, thanks tjaalton
[15:24] <rbasak> vorlon: ready for the Launchpad git switch. Do I need to work out what API call to make and tell you? cjwatson asked us to test on qastaging first.
[15:26] <alkisg> Hi, `apt install` in 18.04 deletes e.g. "/var/cache/apt/archives/sl_3.03-17build2_amd64.deb" right after `apt install sl`. That would be a bug and not a design choice, right?
[15:26] <alkisg> I.e. it autocleans all downloaded debs right after their installation. I think it didn't do that a few months ago, so it must be a recent issue...
[15:27] <rbasak> Could that be intentional to keep things clean?
[15:28] <alkisg> I didn't find any documentation about it, and it would be rather strange to invalidate the purpose of apt caching without documentation...
[15:31] <cjwatson> rbasak,vorlon: I don't recall if there are any usd-import-team repositories on qastaging (hard to check because qastaging does tend to time out an awful lot).  Might be worth creating some if not so that we can make sure they still work.
[15:32] <cjwatson> The API operation would be `ubuntu = lp.distributions['ubuntu']; ubuntu.vcs = 'Git'; ubuntu.lp_save()`
[15:33] <cjwatson> I guess we can find out if the API change works, but it's not clear how much more we can test with all the timeouts :-/
[16:43] <vorlon> cjwatson, rbasak: are you ready for me to run that API operation on qastaging?
[16:44] <cjwatson> vorlon: Sure
[16:47] <vorlon> cjwatson, rbasak: done
[16:47] <cjwatson> https://code.qastaging.launchpad.net/ubuntu/+source/at looks plausible
[16:48] <rbasak> Thanks!
[16:48] <cjwatson> Which I guess is literally the only effect, isn't it
[16:48] <cjwatson> vorlon: I think you can go ahead and do production too
[16:49] <nacc> we probably didnt' update the 'default' repo in qa staging?
[16:49] <cjwatson> Indeed, that's not a concern
[16:49] <nacc> ack
[16:49] <vorlon> cjwatson, rbasak: also done on prod
[16:49] <rbasak> Thank you!
[16:49] <nacc> woop, nice work rbasak, vorlon !
[16:49] <cjwatson> LGTM
[16:49] <nacc> and cjwatson :)
[16:50] <rbasak> I wonder if we should also point HEAD to the applied branches
[16:50] <oSoMoN> doko, FYI I'm tracking the libreoffice autopkgtest failure caused by openjdk 11 with bug #1796361
[16:50] <rbasak> Any opinions on that?
[16:50] <nacc> rbasak: good question
[16:51] <cjwatson> I would, but you know my opinion on applied vs. unapplied
[16:51] <rbasak> That's intended for first timers - they don't necessarily know about quilt, and pointing HEAD to applied/ubuntu/devel would show them exactly what they might expect from master somewhere else.
[16:51] <rbasak> cjwatson: I forget. Did you want everything always applied?
[16:51] <nacc> rbasak: yeah, it's probably a reasonable default -- would change the workflow for developers, but that's not too big of a deal
[16:51] <cjwatson> I've always preferred applied, yes
[16:52] <cjwatson> But don't know git-ubuntu well enough to be certain
[16:52] <rbasak> OK. Consider that decided, though I need to land a code change to make the importer do that, but edge is currently broken, so it won't be for a few days
[16:53] <nacc> rbasak: just update the HEAD on the push?
[16:53] <rbasak> Yeah. We already do, don't we? So we just need to tweak what it sets it to.
[16:54] <nacc> rbasak: uh possibly :)
[16:54] <rbasak> Trivial code change, but I want to get it into the production importer, so it's just a case of going through the snap publication, etc.
[16:54] <rbasak> So as soon as I've fixed edge :)
[16:54] <nacc> lol
[16:54] <nacc> aack
[18:28] <plars> bdmurray: hi, do you think you can take a look at this and see if there's anything else that would be useful? https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1796193
[18:29] <plars> bdmurray: I don't have access to the systems right this minute due to a power outage, but hopefully that will be resolved soon. It's causing some problems with some automated testing that I'm trying to get running
[18:52] <nacc> ibverbs-providers Provides some libraries and Breaks older versions of them. If you specify ibverbs-providers and ibverbs-providers:i386 to be installed, dpkg complains: https://paste.ubuntu.com/p/gTKq8kYnWN/
[18:52] <nacc> why does it do that? the breaks is on a version older than the one specified, afaict
[18:53] <nacc> nm, it's fixed in 18.10!
[18:59] <nacc> LP: #1796388 fwiw
[19:11] <tdaitx> rbasak: regarding https://code.launchpad.net/~tdaitx/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/355346 it is just that this is a fix for the attachment to that bug, not to the bug itself, it came out during last sprint conversations
[19:11] <tdaitx> it's on hold right now
[19:33] <Unit193> rbasak: Plans of having the rest of the repository in VCS?
[19:35] <nacc> Unit193: i think there are plans, but probably not until we do the remiport the world step to fix the main repositories
[19:36] <nacc> Unit193: and then we will phase in universe slowly
[19:36] <Unit193> OK, most of the packages I have an interest in are in universe. :)
[19:42] <nacc> Unit193: fair :)
[19:48] <Unit193> And just last night, I `pull-lp-source $pkg`;scp pkg/debian/patches/*.patch server:wwwdir/source/  and linked someone, having a browsable source would be useful indeed. :)
[19:49] <nacc> Unit193: heh, we can do one-offs of things that are priorities to developers as well
[23:05] <Unit193> cjwatson: Not seen you active, so just going to say thanks for your recent work in twisted!  Didn't see https://github.com/twisted/twisted/pull/1053, and great to hear you might be picking up the ed25519 pull too.  Also glad the openssh/openssl issue seems to have been fixed in a pretty reasonable way (rather than bundling,or whatnot.)
[23:06] <cjwatson> Unit193: np - still a fair distance to having ed25519 working, but we're gradually trundling along
[23:07] <Unit193> Yes, but I still appreciate your work on it.