[06:56] <mitya57> Yeah, this is still failing too: https://launchpadlibrarian.net/431428141/buildlog_ubuntu-eoan-arm64.qtquickcontrols-opensource-src_5.12.4-1_BUILDING.txt.gz
[06:57] <doko> yes, this was not the correct reversion
[08:11] <seb128> doko, I guess you know that but it looks like your binutils revert/fix didn't fix armhf builds
[08:12] <doko> well, you could read 10 lines above
[08:15] <seb128> doko, I close IRC at night so no
[09:36] <LocutusOfBorg> doko, is PR 24708 not enough than to fix the issue? can't we just ignore the change in bfd/compress.c?
[09:37] <doko> I have the fix, the build needs finishing ...
[09:37] <cpaelzer> doko: I'm looking at an odd case (FTBFS) where "-Xlinker --disable-new-dtags" fixes the issue
[09:37] <cpaelzer> but I'd want to get rid of our Delta and therefore better understand
[09:38] <LocutusOfBorg> thanks nice
[09:38] <cpaelzer> the code has plenty of test binaries, and all work as-is except one needing that config tweak
[09:38] <LocutusOfBorg> I have a bunch of stuff in debian uploaded today
[09:38] <cpaelzer> I checked readelf and ldd - the bad binary really can't resolve its lib, but I fail to see why - are there any common places that would be good to check next?
[09:38] <LocutusOfBorg> with the freeze for unstable finished... people are uploading so much
[09:39] <cpaelzer> doko: here some notes that I've taken so far http://paste.ubuntu.com/p/dGQ9yhWk2y/
[10:17] <cpaelzer> doko: I have found that it was an effect of our as-needed default; the test has no dependencies on its own, but depends on a local lib that then needs libnspr4
[10:18] <cpaelzer> thier rpath magic  to resolve that for the tests doesn't work for the "second tier" on ldd/ld.so
[10:19] <cpaelzer> BTW that is bug 925790 that you auto-opened for ggc-9 - I added details there
[10:19] <cpaelzer> hrml bot - debian bug please
[10:20] <Unit193> Debian 925790
[10:31] <rbasak> If a package depends on a virtual package as a _first_ alternative, how does apt behave? I'm not sure how to find such an example in the archive easily for a quick test, so hoping someone will know without me having to construct an example. I know that usually we'll specify a non-virtual package as a first alternative to define the default.
[10:32] <rbasak> But I'm doing some analysis of the archive so I want to cover that case in case someone has done it.
[10:32] <rbasak> Will apt pick an artibrary package to fulfil the virtual dependency or will it prompt the user?
[10:34] <seb128> there is no such prompting existing in apt afaik, it just picks one iirc
[10:34] <seb128> but juliank would probably reply better to that
[10:37] <juliank> we maximize (Multi-Arch: same, installed, same name [real package], essential, xb-important, native, priority, -order in the cache)
[10:37] <juliank> (in current apt, older versions might be different)
[10:38] <rbasak> seb128: juliank: thanks - that's useful
[10:39] <juliank> to be more clear, the multi-arch same thing prefers a multi-arch: same package if its already installed for another architecture
[10:39] <juliank> So given a Depends foo with providers foo1, foo2:foreign, foo2:same, foo
[10:40] <juliank> If you have foo2:foreign installed, it picks foo2:same (well, let's assume foo2:same is realyl the only provider...)
[10:40] <juliank> If you have foo1 installed, it picks foo1
[10:40] <juliank> If neither foo1, foo2* are installed, foo will be installed because it has the same name :)
[10:41] <juliank> This is the comparison operator for two providers: https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/depcache.cc#L986
[10:42] <juliank> oh nice, in case of multiple foreign architectures it prefers them in the order they are configured
[13:05] <doko> apw, infinity: how do we go forward with the glibc autopkg test regressions? do you agree this is a kernel issue?  Asking because we probably will get into some trouble when changing the GCC default next week or so, and the packages are not migrating
[14:28] <LocutusOfBorg> can anybody please set this bug to verification-done? https://bugs.launchpad.net/ubuntu/+source/youtube-dl/+bug/1831778
[14:28] <LocutusOfBorg> looks like I cant
[14:28] <LocutusOfBorg> somewhat I could, but they got deleted
[14:29] <LocutusOfBorg> meh
[14:31] <seb128> LocutusOfBorg, I've hitting launchpad timeouts so maybe the same issue?
[14:31] <seb128> try again, edits worked now for me
[14:31] <seb128> launchpad is quite timeout-y nowadays sadly
[14:44] <LocutusOfBorg> seb128, yes, that was exactly my issue
[14:44] <LocutusOfBorg> I could change all of them at the end
[14:44] <LocutusOfBorg> after many attempts
[14:44] <seb128> good :)
[14:45] <LocutusOfBorg> doko, I didn't say anything, but you might be good to upload in unstable now
[14:45] <LocutusOfBorg> because we are in deep freeze, this means every unblock should now come from proposed-updates
[14:45] <LocutusOfBorg> (sorry for ECHAN)
[15:19] <cjwatson> Yeah I really must sort out the DB triggers refactor (i.e. first take like a day to understand the current triggers ...)
[15:30] <tomreyn> https://wiki.ubuntu.com/ReleaseSchedule needs an update - should i?
[15:30] <tomreyn> (current should point to) https://wiki.ubuntu.com/EoanErmine/ReleaseSchedule
[15:31] <Laney> tomreyn: go for it
[15:41] <tsimonq2> @pilot in
[15:41] <tsimonq2> o/
[15:42] <tsimonq2> ☕
[15:44] <tomreyn> Thanks, Laney. I tried to clean it up, too. https://wiki.ubuntu.com/ReleaseSchedule?action=diff&rev1=48&rev2=49
[16:22] <Eickmeyer> tsimonq2: pulseeffects requires lsp-plugins, not in debian. You can upload my package in https://launchpad.net/lsp-plugins to debian if you want to get that dependency.
[16:25] <tsimonq2> Eickmeyer: My second point still applies, it is in a PPA somewhere that I can grab and inspect?
[16:26] <Eickmeyer> tsimonq2: https://launchpad.net/~mikhailnov/+archive/ubuntu/pulseeffects
[16:26] <Eickmeyer> Took me 10 seconds to find it.
[16:26] <tsimonq2> Eickmeyer: Didn't the author say the PPA version is different from what should be uploaded?
[16:27] <tsimonq2> Right, the versions aren't appropriate for upload.
[16:27] <tsimonq2> The discrepancies between his versions and what should be uploaded need to be addressed.
[16:27] <Eickmeyer> tsimonq2: it's already addressed on his github.
[16:28] <tsimonq2> Eickmeyer: So you'll upload that to a PPA? ;)
[16:28] <Eickmeyer> tsimonq2: He was supposed to do that. I was just trying to get the ball rolling.
[16:28] <tsimonq2> Eickmeyer: Fair enough.
[16:29] <Eickmeyer> tsimonq2: The only discrepencies deal with lintian warnings which are eliminated with the version on github.
[16:31] <tsimonq2> Eickmeyer: ack
[16:31] <Eickmeyer> tsimonq2: My point was you're not going to get it into Debian without lsp-plugins.
[16:31] <tsimonq2> Eickmeyer: Wanna do both?
[16:32] <Eickmeyer> tsimonq2: I suppose I could. I need to get my salsa account fully set-up, and then Ross was going to add me to the Debian Multimedia team, but I've been sidetracked.
[16:33] <tsimonq2> Eickmeyer: I'm also a member of the Debian Multimedia Team, I don't know if I can add you though.
[16:33] <Eickmeyer> Ross is, unfortunately, on vacation for the next 4 weeks and incommunicado.
[16:34] <tsimonq2> Create a Salsa account and we'll see.
[16:34] <tsimonq2> If I can add you, I will.
[16:35] <tsimonq2> Perhaps you've forgotten that I am also a Debian Developer. :)
[16:36] <Eickmeyer> tsimonq2: No, I haven't, but you've been quite busy.
[16:37] <Eickmeyer> tsimonq2: My salsa account (I already had one) is eickmeyer-guest.
[16:37] <tsimonq2> Eickmeyer: Keep bugging me, I won't get annoyed.
[16:37] <tsimonq2> Added.
[16:41] <Eickmeyer> tsimonq2: Thanks
[16:43] <tsimonq2> @pilot out
[16:43] <tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2019-July/040762.html
[16:44] <Eickmeyer> tsimonq2: Are you going to be sticking around for a bit?
[16:44] <tsimonq2> Yeah, ish.
[16:47] <Eickmeyer> tsimonq2: I'm pushing all branches to https://salsa.debian.org/multimedia-team/lsp-plugins
[16:47] <tsimonq2> ack
[16:48] <Eickmeyer> I need to fix the changelog to target unstable, but other than that it should be good to go.
[16:48] <tsimonq2> Can you check if an ITP bug has been filed?
[16:48] <tsimonq2> If not, can you please file one?
[16:48] <Eickmeyer> Sure.
[16:48] <tsimonq2> Thanks.
[17:46] <Eickmeyer> tsimonq2: ITP filed.
[17:48] <Eickmeyer> er... filed.
[17:48] <Eickmeyer> Wierd font, looked like fled. :P
[17:49] <teward> weird font*
[17:49]  * teward resets Eickmeyer's grammar and speech centers
[17:54] <Eickmeyer> teward: ERR: 404 GRAMMAR NOT FOUND
[17:54] <tomreyn> No bootable device -- insert disk and press any key
[17:55]  * Eickmeyer drools in stupor
[17:55]  * teward installs "ChaosOS" onto Eickmeyer's head
[17:55] <teward> :P
[17:56] <sarnold> ENOGRAMR
[17:56]  * Eickmeyer reappears as endgame boss from original Final Fantsy
[17:56]  * Eickmeyer *Fantasy
[17:57]  * Eickmeyer ERR: TYPING NOT FUNCTIONING, TOO MUCH ChaOS
[17:58]  * teward uses REISUB on Eickmeyer.  It's super effective!  Eickmeyer has shut down.
[17:58] <teward> okay back to work.
[17:58] <teward> :P
[17:59] <teward> okay last one: tomreyn: remind me where we keep the obsolete 6.06 installers again?  ;)
[18:00] <sarnold> teward,tomreyn http://old-releases.ubuntu.com/releases/
[18:05] <tomreyn> i'm too slow to replace both sarnold and google.
[18:11] <teward> heh
[18:17] <tsimonq2> Eickmeyer: Link?
[18:18] <Eickmeyer> tsimonq2: For the ITP or https://salsa.debian.org/multimedia-team/lsp-plugins ?
[18:18] <tsimonq2> The ITP.
[18:19] <tsimonq2> I'll go ahead and put your package through The Paces locally.
[18:19] <Eickmeyer> tsimonq2: Can't find the ITP. I was supposed to get a bugreport, will check spam.
[18:22] <teward> did you file it against wnpp?
[18:22] <teward> or a nonexistent source?
[18:23] <Eickmeyer> teward: Yes, I filed it against wnpp using the template in bugreport wnpp
[18:25] <teward> Eickmeyer: what was the subject line ou used?
[18:25] <Eickmeyer> teward: I don't remember. Should I just refile?
[18:25] <Eickmeyer> ERR: COFFEE INEFFECTIVE
[18:26] <tsimonq2> Eickmeyer: The Debian bug tracking system is slow.
[18:26] <teward> ^ this
[18:26] <tsimonq2> If you don't get confirmation one hour after you filed it, it isn't there.
[18:26] <teward> might take some time for it to actually process
[18:26] <Eickmeyer> That must be it then.
[18:27] <teward> Eickmeyer: ERROR: YOU STOLE MY COFFEE
[18:27] <cjwatson> The relevant cron job runs every three minutes.  An hour is surely effective but super-conservative.
[18:27] <Eickmeyer> cjwatson: You saying it might... be a while?
[18:27] <cjwatson> Either I'm missing a joke, or no.
[18:28] <Eickmeyer> cjwatson: Nah, just trying to find my ITP and being unsuccessful.
[18:28] <cjwatson> It's certainly not the instant people expect from typical webapps these days, but it's a few minutes plus however long email takes to get to you
[18:28] <cjwatson> Then it was probably badly formatted in some way that it got rejected
[18:28]  * Eickmeyer will refile
[18:29] <cjwatson> It should have sent you a rejection, but maybe your email system ate it
[18:29] <cjwatson> (Though also, I suppose it's possible that your email hit greylisting on the input side of the Debian BTS; I can't see that part of things)
[18:32] <cjwatson> I don't immediately see your email anywhere, but it's quite a long time since I was involved in Debian BTS admin so I'm pretty rusty on how it's put together
[18:35] <tsimonq2> cjwatson: Somehow I'm not surprised you have perms there. ;)
[18:38] <cjwatson> I was an active admin from 2002 to 2006ish; I haven't done much to it since except occasional bits of support
[18:40] <cjwatson> If I were working on it nowadays the priority would be to give it a decent database backend as a prerequisite for essentially everything else.  (Which I think somebody is in theory working on, maybe ...)
[18:40] <Eickmeyer> Refiled.
[18:51] <Eickmeyer> cjwatson: No rejection, but not receiving an email about it either.
[18:51] <Eickmeyer> cjwatson: Rather, I have received nothing.
[18:55] <cjwatson> Eickmeyer: OK, you'll need somebody actually active to look.  dondelelcaro might be around on some Debian channels (#debian-bugs or #debian-devel on OFTC maybe?) or you could try emailing owner@bugs.debian.org but don't expect a quick response there
[18:58] <teward> Eickmeyer: if you can send to me on Telegram your contents I might be able to file the ITP and reassign owner thanks to some Control knowledge I picked up
[18:58] <teward> assuming of course it still isn't picked up
[18:59] <teward> or you can jsut wait
[19:14] <Eickmeyer> teward: I'll work on it.
[19:15] <teward> ack
[19:15] <Eickmeyer> teward, cjwatson: I even tried to email it to submit@bugs.debian.org directly and I got hit with an "address not found" error.
[19:15] <teward> o.O
[19:15] <teward> from your mail server / service or from submit@bugs.debian.org?
[19:15] <teward> (exact error plz)
[19:16] <Eickmeyer> FROM my mail server (gmail-based) to submit@bugs.debian.org
[19:16] <Eickmeyer> teward: I see what I did wrong. Redoing...
[19:20] <cyphermox> cpaelzer: could I convince you to review a MIR for me when you have a moment?
[19:22] <tsimonq2> Eickmeyer: What'd you do? :)
[19:22] <Eickmeyer> tsimonq2: I manually sent it but to .com instead of .org
[19:22] <Eickmeyer> tsimonq2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931347
[19:22] <Eickmeyer> Either way, it's good now. ^
[19:23] <cpaelzer> cyphermox: you clearly can, but can I do that tomorrow after I slept?
[19:23] <cpaelzer> or is it really urgent?
[19:24] <cpaelzer> cyphermox: I see none as NEW in the queue
[19:25] <cyphermox> no, it's not urgent, it certainly can be tomorrow. I haven't written it quite yet ;)
[19:25] <cyphermox> I'm struggling with high latency and a busy CPU
[19:26] <cpaelzer> I'll check the NEW MIR queue tomorrow then
[19:27] <cyphermox> ta
[19:42] <seb128> bdmurray, hey, I'm curious but what heuristic is used to comment on ubiquity bugs about integrity issues?
[19:42] <seb128> I was expecting squashfs errors but just saw a case where the attach syslog doesn't have any of those but the bot commented on
[19:57] <bdmurray> seb128: which bug was it?
[19:58] <seb128> bug #1835059
[20:03] <bdmurray> seb128: It looks at casper for this line "Identifying... [04ba3a6ca8a6d9e7f686a24ecf67ba43-2]"
[20:03] <bdmurray> seb128: and checks to make sure it matches what the iso file should have
[20:04] <bdmurray> seb128: there is a suspicous bit in casper and ubuqitysyslog - deb cdrom:[Ubuntu 18.04.2 LTS _Bionic Beaver_ - Release amd64 (20190210)]/ kali-last-snapshot contrib main non-free
[20:09] <seb128> bdmurray, so non official iso?
[20:09] <teward> that looks like it's referring to a Kali ISO
[20:09] <teward> which isn't official :p
[20:09] <seb128> is that Identifying number the md5 or something like that?
[20:09] <seb128> I though you were checking for squashfs error in syslog, which is my usual hint for invalid images issues
[20:10] <bdmurray> seb128: its the result of apt-cdrom ident on the iso
[20:11] <seb128> ah, I see
[20:11] <seb128> bdmurray, thx for the info, I learnt something new :)
[20:11] <teward> seb128: wrt #1835077 you subbed Sponsors to, I'd be hesitant to put Sponsors on that until we know whether this is documented somewhere upstream - because this 'directory' they're referring to doesn't seem to be 'standard'
[20:11] <seb128> unsure if that setup is weird
[20:11] <teward> (I don't believe it's ready to even be considered for sponsors)
[20:12] <seb128> teward, I think I disagree with other on what is useful to sponsors
[20:12] <tsimonq2> seb128: I haven't had the chance to respond to your email yet, but yeah.
[20:12] <tsimonq2> You make a good point.
[20:12] <seb128> I'm personally interested in diff/suggestions that have enough sense to hit someone knowledgable on the way of making a fix available
[20:13] <seb128> like if some contributor hint me enough that I can pick up the work and do a fix it's a win for me
[20:13] <seb128> I don't need/require them to go the full way
[20:13] <teward> tsimonq2: go read PMs
[20:13] <teward> you have a dozen
[20:14] <seb128> tsimonq2, no worry, sorry to be arguing
[20:14] <seb128> we maybe need split queues
[20:14] <bdmurray> Oh, look what was in my search history.
[20:14] <bdmurray> https://pkg.kali.org/pkg/console-setup
[20:14] <tsimonq2> seb128: I agree on split queues.
[20:15] <seb128> one for things ready to be uploaded, one for detective work/hints that might be useful to the maintainer to get a fix uploaded
[20:15] <teward> ^ that
[20:15] <bdmurray> I thought we had that already
[20:19] <bdmurray> https://launchpad.net/~ubuntu-reviewers
[20:20] <bdmurray> ^ that's the one for detectives
[20:21] <teward> then it should be a case of end users and triagers NOT subbing sponsors simply because a patch is attached :p
[20:21] <bryce> detailed test cases can be quite helpful.  sometimes more useful than actual patches.  not sure how to detect bug reports with them, though.
[20:29] <seb128> I think a but with a SRU description including test case/regression potential and a debdiff should qualify to stay in the queue though
[20:29] <seb128> even if there is a question on whether that needs to be sent to Debian as well