=== mnepton is now known as mneptok
=== Guest77633 is now known as Cyrus
=== maclin1 is now known as maclin
=== g2 is now known as Iron_monkey
[06:48] <cpaelzer> nacc: you will likely not read this anytime soone so adding rbasak here as well
[06:48] <cpaelzer> rbasak: I did not add skip-applied, I had no  reason and didn't use any special option actually
[06:49] <cpaelzer> of the imlpicit whitelisting if importing I didn't know will take a look and add it right now via a MP
[06:49] <cpaelzer> rbasak: can review that and merge if ok
[06:50] <cpaelzer> nacc: rbasak: I usually use stable, but IIRC last week for "client" side things you asked me to go back to edge - so it might have been edge - let me check
[06:56] <cpaelzer> rbasak: ok so I was on the egde due to the request a few days ago
[06:57] <cpaelzer> rbasak: did I interpret nacc correctly that imports up until the re-import-the-world should be done back on stable?
[06:57] <cpaelzer> rbasak: and if so should I kill the two packages that were imported and instead just add the three of them to the whitelist
[06:58] <cpaelzer> rbasak: I was able to see that they technically import without error - so just adding them to the whitelist would import them "the same way as all others"
[07:07] <cpaelzer> rbasak: https://code.launchpad.net/~paelzer/usd-importer/+git/usd-importer/+merge/333949
[07:20] <pitti> Laney: good morning! do the systemd-upstream tests loop again? http://autopkgtest.ubuntu.com/running#queue-upstream-xenial-amd64 hardly makes any progress, and neither does the artful-i386 queue
[07:46] <cpaelzer> rbasak: nacc: also added an MP to avoid accidential edge/git imports for your review
[08:03] <fabbione> doko: btw, that valgrind bug is showing up again in Debian Experimental
[08:03] <fabbione> doko: it doesn't show in debian Unstable
[08:04] <fabbione> doko: not sure if you are involved with debian toolchain, but i thought you might want to know
[09:16] <Laney> hey pitti
[09:17] <Laney> pitti: We made it so that only 10% of the workers would take upstream tests when the distro queue was huge --- I just reverted that, let's see how we get on
[09:18]  * Laney will watch a log to see if it finishes
[09:22] <pitti> Laney: ah ok, that would explain it
[09:22] <pitti> Laney: that's fine, I was just worried about a test tmpfail-looping and eating resources
[09:23] <pitti> Laney: as the other queues are empty - would this patch also just have used 10% if the other 90% are idle?
[09:24] <mwhudson> why would this be considered a regression? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/armhf/g/golang-dbus/20171120_075357_70f15@/log.gz
[09:25] <mwhudson> i'm a bit confused as to why it thinks there are no tests though, they ran (via autodep8) on other arches
[09:25] <pitti> missing autodep on the runners?
[09:25] <Laney> pitti: it removed the context from 90% of the workers
[09:25] <Laney> fairly brutal
[09:26] <pitti> Laney: ah, I see
[09:26] <mwhudson> pitti: oh so autodep8 is not necessarily installed on all runners?
[09:26] <Laney> mwhudson: looking, one second
[09:26] <pitti> mwhudson: right; it needs to be part of the runner setup charm or cloud-init userdata
[09:28] <mwhudson> hmm it's not listed in testbed-packages in the artifacts, but it's not listed on the arch in ran in either...
[09:28] <mwhudson> i guess that's captured to early or something?
[09:29] <pitti> autodep8 isn't part of the testbed, it needs to be installed on the "outside" runner (side by side with autopkgtest itself)
[09:30] <mwhudson> ah
[09:30] <mwhudson> that makes sense when i actually think about it :)
[09:43] <doko> oSoMoN: libreooffice autopkg test failure on i386, segfaulting
[09:47] <oSoMoN> o
[09:47] <oSoMoN> doko, looking
[10:04] <Laney> mwhudson: fixed!
[10:04] <Laney> thanks for reporting
[10:05] <Laney> I needed to upgrade autodep8 :(
[10:07] <k1l_> Hi, i got a question about the procedure of fixing a bug according to SRU: see bug https://bugs.launchpad.net/ubuntu/+source/corebird/+bug/1730927 The maintainer says he cant get a SRU since the final repos have different majorversions than bionic has got.
[10:07] <ubottu> Launchpad bug 1730927 in corebird (Ubuntu) "Support the new 280 character limit." [Undecided,Fix released]
[10:07] <k1l_> but aiui this would make most packages unpatchable in final repos since the unstable version got a different major release most of the time?
[10:09] <rbasak> k1l_: I've tried to answer in https://bugs.launchpad.net/ubuntu/+source/corebird/+bug/1730927/comments/7 - hope that makes it clear.
[10:09] <ubottu> Launchpad bug 1730927 in corebird (Ubuntu) "Support the new 280 character limit." [Undecided,Fix released]
[10:12] <rbasak> k1l_: sorry, I failed to say that I was going to answer _in_ the bug :)
[10:14] <k1l_> rbasak: alright. this sounds like i interpreted it correctly and it could be patched in the stable repos.
[10:14] <rbasak> k1l_: agreed. Thank you for chasing this up!
[10:23] <rbasak> cpaelzer: actually following discussions with nacc late last week we concluded that the importer should always be run from beta (which we'll create, but initially it'd start off the same as edge)
[10:23] <rbasak> cpaelzer: if you didn't run --skip-applied then something went wrong with your import I think.
[10:23] <rbasak> The applied branches didn't get imported, and we don't know why.
[10:24] <rbasak> nacc tried it and he did get the applied branches updated, which is why he thought you'd probably run it with --skip-applied.
[10:24] <rbasak> So if you didn't, I'm not sure we know what happened.
[10:27] <cpaelzer> rbasak: hmm :-/
[10:27] <cpaelzer> rbasak: ok so lets summarize the different things in flight here
[10:27] <cpaelzer> 1. my import didn't work as it should, should I remove them for now?
[10:28] <cpaelzer> I didn't realize the applied branches were missing, but if so what is uploaded atm is incomplete
[10:30] <cpaelzer> too bad, as I imported from edge and as I read that would have been correct after all
[10:30] <cpaelzer> my console log is gone so I can't check why it worked for me
[10:31] <cpaelzer> in the past being on xenial was a difference to you and nacc sometimes
[10:31] <rbasak> I don't think there's any need to remove them. It's better than nothing, and we haven't declared "hash stability" yet. I'm pretty sure didrocks would prefer to have them than nothing at all.
[10:31] <cpaelzer> I'm ok with that
[10:32] <rbasak> The rest is accurate. I think Xenial shouldn't make a difference now that the snap embeds the necessary dependencies (and versions).
[10:32] <cpaelzer> so I could kick of the gtk+3.0 import as well then rbasak?
[10:32] <cpaelzer> that was taking too long last week
[10:32] <cpaelzer> or would it be enough to accept the MP which whitelists it
[10:32] <rbasak> So you stopped it?
[10:32] <didrocks> yes, I don't really care about git history and hashes for now, the community is just going to cp the content (just having access to latest easily for them will help once we get hash stability and can branch)
[10:32] <cpaelzer> I let it run, but it welcomed me with a timeout this morning
[10:32] <rbasak> I mean: that's fine, just want to understand current status.
[10:32] <rbasak> OK
[10:33] <cpaelzer> rbasak: actually I ahve the local tree
[10:33] <cpaelzer> rbasak: maybe there is some --re-import flag or so to not do it all over again
[10:33] <rbasak> cpaelzer: I wonder if you could try again locally and tee the output to a log?
[10:33] <cpaelzer> to just check on latest status and push then
[10:33] <rbasak> You can use --no-fetch I think.
[10:33] <rbasak> But that might imply --no-push. I don't recall.
[10:33] <cpaelzer> it does
[10:33]  * rbasak doesn't know if there's a --no-no-push.
[10:34] <cpaelzer> hehe
[10:34] <cpaelzer> let me check on this gtk+3.0 first
[10:34] <rbasak> cpaelzer: if possible, I'd like you to try again to see if you can reproduce the previous problem but with log output (-v).
[10:34] <cpaelzer> this issue was on gnome-shell
[10:34] <cpaelzer> so I'd run that again in another console
[10:34] <rbasak> cpaelzer: if that doesn't work or is difficult, then we can just add to the whitelist. Either way we can certainly add to the whitelist.
[10:34] <cpaelzer> but with verbose and keeping the logs
[10:35] <cpaelzer> rbasak: the MP for the whitelist is up
[10:35] <rbasak> Right now, after adding to the whitelist, the central importer will only run after it sees an upload. Someone still has to manually do stuff (though I can do it from the bastion).
[10:35] <cpaelzer> rbasak: then we will do this
[10:35] <cpaelzer> 1. you can review and merge the MP to whitelist
[10:35] <cpaelzer> 2. I will create a local import of gnome-shell with logs to check what might have happened
[10:36] <cpaelzer> 3. I check if I can re-use all the work done on gtk+3.0 by uploading it
[10:36] <cpaelzer> well for 3. not just push but some sort of git ubuntu import --flags
[10:37] <rbasak> I can do that, but won't updating the whitelist potentially clash with our examination in case there is an upload for that package?
[10:37] <cpaelzer> rbasak: ok hold back the merge until I have a log provided
[10:37] <cpaelzer> rbasak: but even so a --no-fetch would then still be the same
[10:38] <cpaelzer> gnome shell import with --no-push is running to create logs
[10:38] <cpaelzer> now looking at gtk+3.0
[10:40] <cpaelzer> even with "--no-clean --no-push" it starts over again, but just pushing the repo is too unclean
[10:40] <cpaelzer> I start it again fresh
[10:40] <cpaelzer> we can afford those few hours
[10:40] <cpaelzer> and I'll collect logs on that as well to be sure
[10:41] <cpaelzer> my problem with the last gtk+3.0 import was that a screen lock implies I need to unlock gpg again
[10:41] <cpaelzer> and since it was still running when I went EOD that was the case
[10:41] <cpaelzer> due to that the timeout eventually
[10:41] <cpaelzer> both now running fine and logging away rbasak
[10:41] <cpaelzer> I'll ping with logs once they completed
[10:42] <rbasak> Thanks!
[10:48] <LocutusOfBorg> pitti, how do you feel about rfkill sync? the delta seems mostly upstart-only, but I prefer to not touch it
[10:50] <pitti> LocutusOfBorg: looking
[10:51] <pitti> LocutusOfBorg: confirmed, looks good; so you want me to sync? doing
[10:52] <LocutusOfBorg> <3
[11:18] <cpaelzer> rbasak: gnome-shell is complete - what would I want to look for?
[11:19] <cpaelzer> branches with --applied?
[11:20] <cpaelzer> http://paste.ubuntu.com/26004584/
[11:20] <cpaelzer> rbasak: LGTM in the log
[11:21] <cpaelzer> it has applies and unapplied branches
[11:21] <cpaelzer> even the remote actually has them already from last week
[11:21] <cpaelzer> rbasak: but then I didn't follow your discussion back then, what was missing?
[11:21] <rbasak> cpaelzer: is importer/applied/ubuntu/devel recent?
[11:21] <rbasak> cpaelzer: it appeared that none of the applied branches had been updated
[11:22] <rbasak> (in the other repo the other day)
[11:22] <cpaelzer> hmm, no it seems old
[11:22] <rbasak> cpaelzer: so if the applied branches are current, then it's not the same problem.
[11:22] <cpaelzer> 2.28.1~git20091020-1 of 2009
[11:22] <rbasak> Interesting. So you can reproduce.
[11:22] <cpaelzer> yeah by doing "git ubuntu import --verbose --directory /tmp/import/gnome-shell --no-push gnome-shell"
[11:23] <rbasak> Does the hash match the output of line 4773 in your pastebin?
[11:23] <cpaelzer> maybe that fetched the state as-is ?
[11:23] <cpaelzer> I can re-run with no-fetch if needed
[11:23] <cpaelzer> the hash matches
[11:24] <cpaelzer> rbasak: can you see from the log if it just fetched what it imported last week?
[11:24] <rbasak> OK: but the hash is old?
[11:24] <cpaelzer> yes
[11:24] <cpaelzer> the hash matches and it is old
[11:24] <cpaelzer> it seems all applied are the same
[11:24] <cpaelzer> look at this
[11:24] <cpaelzer> http://paste.ubuntu.com/26004608/
[11:25] <cpaelzer> it seems all applied are "on" this hash
[11:25] <rbasak> Let me see if I can reproduce here
[11:25] <rbasak> Can you confirm your snap version please?
[11:25] <cpaelzer> I also started one with --no-fetch as well to check on that
[11:25] <cpaelzer> was 335 this morning
[11:25] <cpaelzer> just a sec
[11:26] <cpaelzer> yes still on 335
[11:26] <rbasak> OK
[11:26] <cpaelzer> rbasak: you might need --no-fetch as well
[11:27] <cpaelzer> when you try to reproduce
[11:27] <rbasak> But you didn't in that pastebin, right? I don't understand why you think I may need it.
[11:28] <cpaelzer> I didn't use in the pastebin and got to the same result
[11:28] <cpaelzer> as last week
[11:28] <cpaelzer> but maybe I "now" got to the same result as it just fetched many things
[11:28] <cpaelzer> so as lon as gnome-shell is in usdi as a repo anything without --no-fetch might not be a valid reproduce of the actual issue
[11:29] <rbasak> I see
[11:41] <doko> oSoMoN: I see that this failure gets ignored by other packages: gcc-5 libreoffice/1:5.4.1-0ubuntu3
[12:52] <ginggs> doko: hint just needs updating? https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/2652
[12:55] <rbasak> cpaelzer: reproduced
[12:56] <doko> ginggs: -> #ubuntu-release
[13:01] <cpaelzer> rbasak: ok, glad to hear it is not me
[13:01] <cpaelzer> OTOH it means "new bug"
[13:02] <cpaelzer> :-/
[13:02] <cpaelzer> didrocks: sorry for the delays, but well things are in development - better to catch those now
[13:03] <didrocks> cpaelzer: no worry! better to catch that before we go all in ;)
[13:03] <didrocks> and thanks for keeping me posted!
[13:04] <cpaelzer> yw
[13:12] <doko> oSoMoN: is the i386 LO autopj
[13:12] <doko> oSoMoN: is the i386 LO autopkg test failure addressed with your recent upload?
[13:33] <oSoMoN> doko, that upload is to make LO icu60-friendly, it's not related to i386 autopkgtests failures
[13:35] <oSoMoN> doko, the i386 failures look related to bug #1699772
[13:35] <ubottu> bug 1699772 in linux (Ubuntu) "linux-image-4.13.0-12-generic, linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic | Regression: many user-space apps crashing" [Critical,Confirmed] https://launchpad.net/bugs/1699772
[15:01] <rbasak> !dmb-ping
[15:01] <ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
[15:29] <doko> seb128, didrocks, Laney: there are a lot of autopkg test failures for gvfs triggered by various packages. afaics none yet blocking
[15:43] <seb128> doko, those seem to be "Error initializing camera" errors from gphoto so probably a problem in that stack
[16:06] <rbasak> oSoMoN: BTW, it's odd that https://launchpad.net/~osomon/+uploaded-packages lists only a tiny subset of your actual sponsored uploads.
[16:06] <rbasak> oSoMoN: is it that your changelog email address isn't registered in Launchpad perhaps?
[16:07] <rbasak> See http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*tilloy*&sponsoree_search=name for example.
[16:07] <oSoMoN> I use my @canonical.com e-mail address
[16:07] <oSoMoN> and it's registered in LP
[16:07]  * rbasak doesn't know then
[16:09] <oSoMoN> it's weird indeed
[16:09] <seb128> rbasak, could it be that this package only list the most recent upload of a package (by serie)?
[16:10] <seb128> like if you upload 15 times libreoffice to xenial you only get the most recent one
[16:10] <rbasak> I thought it listed all uploads.
[16:10] <oSoMoN> that would make sense, as there's one chromium-browser entry for artful, and one for bionic
[16:10] <rbasak> But also, oSoMoN has uploaded to previous series.
[16:10] <rbasak> Oh
[16:11] <seb128> it seems to limit to 1
[16:11] <seb128> like I looked for Till or robert-ancell
[16:11] <seb128> who often upload the same packages
[16:11] <rbasak> I suppose that could explain it then!
[16:11] <seb128> and they also only have 1 instance of package/serie
[16:11] <seb128> but that's just guessing
[16:11]  * rbasak would prefer it not to limit for DMB application review purposes
[16:11] <seb128> could be a question for #launchpad
[16:15] <Laney> I think it's more that many of the uploads are copies and those aren't recorded as sponsorships (e.g. https://launchpad.net/ubuntu/+source/chromium-browser/62.0.3202.89-0ubuntu0.14.04.1213)
[16:17] <seb128> Laney, well, if you look at https://launchpad.net/~robert-ancell/+uploaded-packages ... I'm pretty sure robert did more gnome-software uploads than that
[16:17] <seb128> there is 1 for artful on that page
[16:17] <Laney> we're not talking about the sponsorship miner?
[16:17] <seb128> and he doesn't do copies afaik
[16:17] <Laney> let's see one that's not listed?
[16:18] <seb128> Laney, dunno, I was replying to "it's odd that https://launchpad.net/~osomon/+uploaded-packages lists only a tiny subset of your actual sponsored uploads."
[16:18] <seb128> Laney, for robert you can take https://launchpad.net/ubuntu/+source/gnome-software/3.25.91-1ubuntu3 for example
[16:20] <Laney> so it looks like it shows the currently published version
[16:21] <seb128> ah, could well be
[16:21] <seb128> unsure if that's by design or buggy though
[16:22] <Laney> yeah don't remember
[16:22] <Laney> I used to use the miner back in DMB days
[16:22] <Laney> so might not have noticed
[16:44] <clivejo> is gunzip broken in bionic?
=== Iron_monkey is now known as g2`
[17:59] <dmj_s76> sforshee: This bug just got brought to my attention: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1089195
[17:59] <ubottu> Launchpad bug 1089195 in update-manager (Ubuntu) "linux-headers will eat your inodes on LTS." [Undecided,Confirmed]
[18:05] <sarnold> clivejo: it might be, I saw someone else complain about it last week
[18:05] <sarnold> clivejo: please file bug :)
[18:10] <sarnold> dmj_s76: wow, what a dumping ground of a bug. it's filed against update-manager but more than one person in ther comments that it happened on their server systems with unattended-upgrades installed, etc
[18:18] <sforshee> dmj_s76: that's the same for all kernel packages, 'apt-get autoremove' does remove them though
[18:32] <dmj_s76> sforshee: Yeah, this was commented to me as well.  It's described as "Not that difficult to recover from once you know what's going on and how to fix it, but really annoying the first time."
[18:33] <dmj_s76> Essentially, you get a broken system if you set unattended upgrades and expect that to work unattended.
[18:35] <sforshee> dmj_s76: it's been discussed before, though I wasn't much involved. There are definitely some issues with automatically removing kernel packages, not sure if they were insurmountable
=== kmously is now known as kmously-afk1hr
=== kmously-afk1hr is now known as kmously
=== santa is now known as Guest73570
=== Guest73570 is now known as santa__
[22:20] <doko> mdeslaur, cpaelzer: your postgresql-9.6 upload to bionic went wrong
[23:18] <slangasek> rbasak, nacc: so the lp:ubuntu remapping, did that happen?  and does the branch that was at bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/shim-signed/ still exist somewhere?  My understanding was that only the mapping was going to be changed, but I don't seem to find that branch now
[23:26] <rbasak> slangasek: we haven't actually made any mapping changes yet
[23:26] <slangasek> hmm ok
[23:27] <rbasak> AIUI the bzr mappings are independent
[23:27] <slangasek> rbasak: then I'll chase up the question of the MP I thought I saw and can no longer find with cyphermox instead, thanks :)
[23:27] <rbasak> And separately there's the default VCS of the ubuntu project
[23:27] <slangasek> right