[02:07] <DarkTrick> General question: Why is bugzilla necessary, if there is launchpad?
[02:07] <DarkTrick> As my understanding, bug reports can be filed with both, but launchpad seems to also include a deploy mechanims.
[02:22] <sarnold> launchpad was written because bugzilla wasn't the kindest thing to work with
[02:29] <DarkTrick> what would now be the difference between filing a bug in bugzilla vs filing one in launchpad?
[02:29] <DarkTrick> e.g. thunar bugs can be filed in both systems
[02:35] <Unit193> thunar is part of Xfce, they use bugzilla as their tracker whereas Launchpad is Ubuntu's bugtracker for *distro* bugs.  If you're asking "Why don't they set up Launchpad?" well that's much easier said than done, I'm only aware of one instance ever.  It's basically open core, not made for others to set up a clone.
[02:36] <Unit193> (In time, Xfce may move to Gitlab and its "issue" system)
[02:43] <DarkTrick> Unit193, "distro bugs" are bugs related to the interaction between the software/package and the distro?
[02:44] <DarkTrick> For example: thunar crashes on raspi .... ?
[02:59] <Unit193> DarkTrick: I'd try the latest one, if it's still an issue then I'd report on upstream's tracker.
[03:34] <DarkTrick> Unit193, that was just an example to check, if I understood it correctly
[03:35] <DarkTrick> but if I understand you right, you would report a "thunar crash on raspi" to bugzilla of thunar (as it is their bug-tracker)
[03:36] <Unit193> After checking the latest released version*
[03:41] <DarkTrick> So, what would be a "distro bug" then?
[03:42] <DarkTrick> (I don't see a dividing line)
[03:47] <Unit193> Sometimes it's a configuration or integration issue, or if you don't check the latest version.  (It doesn't help that I assist with maintaining thunar, soo.)
[03:47] <Unit193> Different people see that line differently.
[04:09] <DarkTrick> Unit193, thank you
[04:31] <sarnold> Unit193: heh, you know I've actually seen another launchpad instance up somewhere in the wild..
[04:31] <Unit193> sarnold: I know which one, because there's only one! :P
[04:31] <sarnold> Unit193: hah. of course you do :D I shoulda known.
[04:33] <Unit193> Granted, I have to *find* it every time...And to be fair, there's a chance you linked me the initial time.
[04:35] <sarnold> but if you can find it again, that's something. :)
[04:42] <Unit193> You mean, https://quickbuild.io/ ?
[04:45] <Unit193> I didn't think it was really updated, but https://quickbuild.io/~kb9vqf/+archive/ubuntu/mythtv-029 seems to indicate it is.
[04:46] <sarnold> Unit193: there we go!! that's the one :)
[05:45] <cpaelzer> rbasak: the SRU template that I added already is correct
[05:46] <cpaelzer> rbasak: just ignore the exagerrated initial report
[05:56] <cpaelzer> mruffell: I don't immediately see the issue
[05:56] <cpaelzer> mruffell: is this reproducible, e.g. if you just retry the build?
[05:56] <mruffell> cpaelzer: yes, it is
[05:56] <cpaelzer> what is the config of that PPA that you use?
[05:57] <cpaelzer> any odd dependencies enabled?
[05:57] <mruffell> it is reproducible on each build
[05:57] <mruffell> the only strange thing is a private ppa, let me check deps
[05:58] <mruffell> there are no dependencies enabled
[05:58] <cpaelzer> I'm comparing it to the last good build now ...
[05:59] <mruffell> on the last good build, posix_openpt and openpty both PASS
[05:59] <cpaelzer> mruffell: just to eliminate differences, can you on the ppa enable proposed in the dependencies
[06:00] <cpaelzer> because that is how the e.g. SRUs will build
[06:00] <cpaelzer> I'm not really expecting this to be the difference
[06:00] <cpaelzer> that breaks it
[06:02] <mruffell> okay, I have resubmitted the build with -proposed enabled
[06:05] <mruffell> cpaelzer: if you are wondering, I'm making a test package for LP 1681839, which someone is now experiencing on xenial. We have a solid reproducer now.
[06:05] <cpaelzer> mruffell: I have prepped and kciked a local build and a PPA rebuild test of my own - just to be sure; continuing checking the logs now
[06:05] <cpaelzer> oh the solid reproducer surely was a great help
[06:06] <cpaelzer> but I'd try to help you no matter what - no need to explain :-)
[06:06] <mruffell> =)
[06:07] <cpaelzer> next difference, the PPA is not building debug symbols - that aagin should make no difference - but I see DEB_BUILD_OPTIONS=noautodbgsym...
[06:08] <cpaelzer> the next obvious diff are your 4 patches
[06:08] <cpaelzer> for the sake of eliminating options, have you tried rebuilding without them?
[06:08] <mruffell> the 4 patches are to the same file, and should have no effect on the openpt testcase
[06:08] <mruffell> but I haven't yet
[06:09] <mruffell> it fails with -proposed added, on the same openpt tests
[06:11] <cpaelzer> It sounds vaguely familiar, like failing these tests on container based builds on armhf in the past
[06:11] <cpaelzer> but why should that hit these builds now ... ?
[06:12] <mruffell> google brought me to LP 1641615 since it mentions the same failing testcase
[06:12] <mruffell> but you resolved that years ago
[06:12] <cpaelzer> heh - I know that guy
[06:13] <cpaelzer> mruffell: https://salsa.debian.org/libvirt-team/libvirt/commit/2be70b3 ?
[06:13] <mruffell> hmmm intriguing
[06:14] <mruffell> I'll add the patches and give it a go
[06:15] <cpaelzer> sure, but you should know that my rebild test started to complete builds successful https://launchpad.net/~paelzer/+archive/ubuntu/xenial-test-rebuilds/+packages
[06:15] <cpaelzer> no amd64 yet, but ppc & s390x are good already
[06:16] <mruffell> even more interesting
[06:16] <cpaelzer> still - try that patch just so we know if it would help your case
[06:17] <cpaelzer> ha and x86 fails
[06:17] <cpaelzer> same reason
[06:18] <cpaelzer> some of the bumps in Xenial to the libs might have made it an FTBFS there
[06:18] <cpaelzer> or changes in the build env, but I'd not have heard of any
[06:19] <cpaelzer> mruffell: I can even recreate the same locally in sbuild
[06:19] <cpaelzer> as there the chroot has the same attributes
[06:19] <mruffell> interesting, my xenial vm doesn't recreate it. Its not fully patched though
[06:19] <cpaelzer> nono in a VM you'd have full pty
[06:19] <cpaelzer> only triggers in chroots
[06:20] <cpaelzer> like sbuild/pbiuld/...
[06:21] <cpaelzer> mruffell: I'm already building with the fix I linked applied
[06:21] <cpaelzer> I should know in ~3-5 minutes if this is a fix to the FTBFS
[06:21] <mruffell> cpaelzer: same here. Just submitted a second ago
[06:21] <cpaelzer> if that turns out to be true we just open a bug and you can tag and close it with your upload
[06:22] <mruffell> sounds like a good plan
[06:30] <cpaelzer> mruffell: fix doesn't apply cleanly to xenial
[06:30] <cpaelzer> ../../../../gnulib/tests/test-openpty.c:47:24: error: 'ENENT' undeclared (first use in this function)
[06:31] <mruffell> fun times.
[06:31] <cpaelzer> mruffell: I have filed https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1843674 for us
[06:32] <cpaelzer> Diving into my sbuild env to check what we could do ...
[06:33] <mruffell> cpaelzer: thanks for filing the bug!
[06:36] <cpaelzer> ok I have it in the build env down to the gcc call that breaks
[06:36] <cpaelzer> ENENT sounds wrong right?
[06:36] <cpaelzer> ENOENT ?
[06:37] <mruffell> yeah, ENENT is not defined in <errno.h>
[06:37] <cpaelzer> yep that gets it working
[06:37] <cpaelzer> there surely was a fixup later
[06:37] <cpaelzer> let me check git
[06:41] <cpaelzer> mruffell: https://salsa.debian.org/libvirt-team/libvirt/commit/7baa0daf8b104fa9b8dafd70dd9ec4bdd9ccee5a
[06:41] <cpaelzer> and https://salsa.debian.org/libvirt-team/libvirt/commit/0ce5eb75bdeaa3ef306457a03ed74b6a6bd65cba
[06:42] <cpaelzer> "recent debootstrap" might be the reason here as well
[06:42] <cpaelzer> throwing that into my build as well
[06:42] <mruffell> would you look at that
[06:42] <mruffell> yep, let's give it a go
[06:42] <cpaelzer> 'll eventually probably push you a branch somewhere to mcombine witho your work
[07:02] <cpaelzer> mruffell: oh I frogot - the build works now
[07:02] <cpaelzer> mruffell: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1843674/comments/2
[07:03] <mruffell> cpaelzer: excellent! Thanks again =)
[07:24] <cpaelzer> doko do the issues I see with new binutils in bug 1843394 ring any bell ?
[12:06] <doko> sforshee: replied to 1843458, empty linux-source package :-/
[12:08] <doko> cpaelzer: I'll have a look
[12:08] <ahasenack> good morning
[13:26] <doko> Laney: why do you keep the pcre2 changes in vte2.91?
[14:28] <Laney> doko: if you're saying they can be dropped, I didn't know that, nobody told me
[14:41] <doko> Laney: well, the desktop team pushed for pcre2 promotion ...
[14:42] <Laney> ok
[14:43] <seb128> doko, we didn't, jbicha did iirc
[14:45] <Laney> want to know the cool thing?
[14:45] <Laney> it's already dropped :D
[14:46] <Laney> the changelog is a copy and paste mistake
[14:46] <Laney> happy doko is happy
[14:46] <seb128> :)
[14:48] <cpaelzer> doko: dovecot-antispam in the eoan rebild seems to be a LP infra problem
[14:48] <cpaelzer> doko: I'd love to just hit rebuild at https://launchpad.net/ubuntu/+archive/test-rebuild-20190906/+build/17542928 but I can't
[15:03] <seb128> doko, those ftbfs you are opening, any idea why -Wno-error=deprecated-declarations isn't working?
[15:03] <doko> cpaelzer: given back, but that's the third time ...
[15:03] <doko> seb128: any concrete example?
[15:04] <seb128> e.g https://bugs.launchpad.net/bugs/1843744
[15:04] <seb128> hum, I guess the failure might not be the deprecated/first error but
[15:04] <seb128> ../../../libdbusmenu-glib/defaults.c:77:13: error: G_ADD_PRIVATE [-Werror]
[15:05] <seb128> though that doesn't state what the error is
[15:06] <rbasak> vorlon: could you delete my mysql-8.0 upload from eoan-proposed please? It didn't achieve what it was supposed to achieve, I'll be a week or two before I can get back to it, and in the meantime I understand it's entangling with other things (PHP?)
[15:07] <vorlon> rbasak: I don't see it entangling anything else, what do you see?
[15:07] <rbasak> bryce: ^?
[15:07] <vorlon> I don't mind deleting it - but I was explicitly checking what else was entangled to know what needed no-change rebuilds if I deleted it
[15:08] <rbasak> There are no API/ABI changes in mysql-8.0 between release and proposed, so I don't think no-change rebuilds would be needed?
[15:08] <rbasak> otp, I'll look deeper in abit
[15:09] <doko> seb128: is that symbol dropped?  maybe a warning emitted by one of the included header files?
[15:09] <seb128> doko, I don't think the symbol is dropped, it's deprecated in the code just unsure why it hits a warning not a deprecated one ... I'm just going to fix the deprecation, easier, thx
[15:10] <bryce> rbasak, vorlon php-horde-activesync and php-horde-db seem to have mysql ties
[15:11] <doko> seb128: the deprecation warning is about g_type_class_add_private
[15:12] <seb128> doko, right, it's not unclear what it doesn't like about G_ADD_PRIVATE to me
[15:12] <seb128>  ../../../libdbusmenu-glib/defaults.c:77:13: error: G_ADD_PRIVATE [-Werror]
[15:12] <seb128> but it doesn't tell what the error is
[15:13] <cjwatson> cpaelzer: LP infra> in what way?
[15:13] <cpaelzer> cjwatson: build issue without any log in https://launchpad.net/ubuntu/+archive/test-rebuild-20190906/+build/17542928 (before it was restarted)
[15:14] <cpaelzer> cjwatson: and I keep saying "LP infra" when I mean builders - sorry for that
[15:14] <doko> seb128: I asked you to look for a #warning statement in one of the header files ...
[15:14] <vorlon> bryce: but I don't see that either of these packages are blocked in -proposed as a result of mysql-8.0 being there
[15:14] <cjwatson> cpaelzer: OK, that sometimes means a network problem between buildd-manager and the builder, and sometimes means that the build ran amok and crashed the builder VM
[15:14] <seb128> doko, ah ok, I didn't get that bit before, will do, thx for the hint
[15:15] <bryce> vorlon, I don't know what is blocking them tbh
[15:15] <vorlon> bryce: I only see php-horde-mime with a failing autopkgtest, autopkgtests test against the release versions of all other packages by default, and I don't see that the failing autopkgtests pull in mysql-8.0 from -proposed
[15:16] <cjwatson> doko: third time> I think you must be misremembering; there is only one previous record of that build failing in our logs
[15:19] <cjwatson> There are vaguely network-blip-like symptoms in the logs here but it's hard to be certain
[15:19] <doko> cjwatson: hmm, I gave back all failed builds twice for the test rebuild ppa, but maybe one of them didn't complete
[15:19] <cjwatson> That would be to be expected, I think, given that the queue is deep
[15:20] <cjwatson> Lots of builds will be getting exactly the same score, and in that case the tie-breaker is first-in-first-out
[15:20] <doko> jamespage: simplestreams dep-waits on python-swift. is this expected?
[15:23] <powersj> doko, https://bugs.launchpad.net/ubuntu/+source/simplestreams/+bug/1841277 server will look at it next week
[15:23] <doko> powersj: ta
[19:30] <kyrofa> Hey folks, the robotics community is pinging me about https://bugs.launchpad.net/ubuntu/+source/urdfdom-headers/+bug/1817595 . A debdiff is attached there, can we get a pair of eyes on it? Does anything more need to happen?
[19:38] <kyrofa> sil2100, I suppose you're the vanguard today, huh. That's probably a question for you ^
[19:44] <juliank> kyrofa: You're one step too far, the next step would be to request sponsorship
[19:44] <juliank> Or well, ubuntu-sponsors is subscribed
[19:45] <juliank> but like that's sponsorship territory atm, not really SRU team stuff
[19:45] <juliank> IMHO This also needs a proper test case, not a Dockerfile that pulls patched versions from the PPA
[19:47] <juliank> FWIW, I have no intention of sponsoring this upload, it's too complex
[19:48] <kyrofa> juliank, that type of feedback would be useful in the bug, if you don't mind
[19:49] <juliank> Ah, it's just my personal opinion
[19:49] <juliank> I'll add some notes, though
[19:50] <kyrofa> juliank, that would be excellent, thank you. Even just the feedback about proper tests would be useful
[19:51] <kyrofa> I just don't know enough about SRU's to help them on their journey, best I can do is find someone who does :)
[19:55] <juliank> kyrofa: basically same procedure as for normal upload, except that you test it after the upload, and that SRU team approves the uploaded package rather than release team / automatic
[19:55] <juliank> and yes, version numbers are different
[19:58] <juliank> kyrofa: I think the main blocker for me (when looking at sponsoring it) is that I'd want someone who commits to actually testing it and drive down any autopkgtest regressions
[19:59] <juliank> As I'd be fine uploading it if you say you're committed to actually driving it, but I wouldn't want to drive that myself
[20:00] <juliank> same for somebody else
[20:00] <juliank> like I don't care who is committed to driving this
[20:03] <kyrofa> juliank, I think Jose would commit to that, they have a vested interest in this going through, and I can  help with autopkgtest failures. I'll ask for him to state it on the bug if you like