[06:30] <jibel> vorlon, hi, about https://code.launchpad.net/~jibel/ubiquity/+git/ubiquity-1/+merge/374920 do you want to discuss the design further with mpt or it's okay to merge it now and possibly update the UI later?
[08:10] <andrewsh> I’m wondering whether anyone is checking https://launchpad.net/~ubuntu-wiki-editors/+members; it seems I’m unable to edit the wiki without being a member of this?
[08:11] <RikMills> popey: ^?
[08:50] <popey> andrewsh: approved
[08:50] <popey> thanks RikMills
[08:50] <andrewsh> popey: thanks
[09:25] <GunnarHj> Hi cjwatson, can you please look at the discussion at https://answers.launchpad.net/launchpad/+question/685319 . I speculated a bit, but don't know about possible procedures in cases like this.
[09:30] <cjwatson> Yeah, nor am I, I was going to dig around a bit today
=== cpaelzer__ is now known as cpaelzer
[10:44] <cpaelzer> rafaeldtinoco: IIRC you wanted to repro 1849720 right?
[10:44] <cpaelzer> be careful thou, since I used ZFS in my setup and that won't work nicely with the mainline kernel builds (lacking the ZFS module)
[10:44] <cpaelzer> just to avoid you running into similar issues
[10:44] <rafaeldtinoco> cpaelzer: I have not tried with q35 yet
[10:45] <rafaeldtinoco> I had to move my VMs (win2019) to an intel only machine
[10:45] <rafaeldtinoco> so that would be my 1st move now
[10:45] <cpaelzer> ok
[10:45] <rafaeldtinoco> and cascardo stole the icelake machine i was going to use =(
[10:45] <rafaeldtinoco> bad cascardo
[10:45] <rafaeldtinoco> :o)
[10:45] <cpaelzer> rafaeldtinoco: I have an ISO on horsea
[10:45] <cpaelzer> we might work together on that
[10:45] <rafaeldtinoco> cpaelzer: my win2k9 is ready
[10:45] <rafaeldtinoco> all updated, same kernel
[10:46] <rafaeldtinoco> i literally have just to change to q35 and test
[10:46] <rafaeldtinoco> lets see
[10:46] <cpaelzer> ok
[10:46] <cpaelzer> I had a bug update on that bug held by by timeouts
[10:46] <cpaelzer> added it now
[10:46] <cpaelzer> leaving the repro to you then, as you seem much deeper into it already
[10:46] <cpaelzer> thanks btw
[10:46] <rafaeldtinoco> on that one ?
[10:47] <cpaelzer> yes on that bug
[10:47] <cpaelzer> just a question to the latest external bug updater
[10:47] <rafaeldtinoco> the first user was a bit lost in providing feedback
[10:47] <rafaeldtinoco> this last one is much better
[10:47] <cpaelzer> as he indicated it might be host kernel related
[10:47] <rafaeldtinoco> yep
[10:47] <rafaeldtinoco> but the last user has 5.3 and 1st had 5.0
[10:47] <rafaeldtinoco> iirc
[10:47] <rafaeldtinoco> ill try both if cant repro
[10:47] <cpaelzer> they all complained in 19.10 which would be 5.3 all the time
[10:48] <cpaelzer> maybe odd upgraders
[10:48] <cpaelzer> so if (IFF) you can repro semi-bisecting the kenel ould be great
[10:48] <rafaeldtinoco> yep I think the 1st was right after upgrade
[10:48] <rafaeldtinoco> maybe using old kernel still
[10:48] <rafaeldtinoco> win2019crashq35.xml -> moving on, will let u know
[10:48] <cpaelzer> see comment #19, even this guy reports it as "after going 5.0 -> 5.3"
[10:48] <rafaeldtinoco> true
[10:48] <cpaelzer> yeah, I'll stop disturbing you - hear you later then
=== ricab is now known as ricab|lunch
[13:40] <cpaelzer> doko: do you really think we need a new MIR for postgresql-12?
[13:40] <cpaelzer> I've checked and 10 / 11 also just got adopted in the past
[13:40] <cpaelzer> I already had powersj subscribe our Team (so responsbility is clear)
[13:40] <cpaelzer> ahasenack: ^^ FYI
[13:41] <cpaelzer> that is bug 1851396
[13:41] <ubottu> bug 1851396 in postgresql-12 (Ubuntu) "[MIR] postgresql-12" [High,Incomplete] https://launchpad.net/bugs/1851396
[13:41] <doko> cpaelzer: hmm, I think I checked the subscriber status before filing the issue ...
[13:41] <doko> ok, promoting
[13:42] <cpaelzer> thank you doko
[13:43] <cpaelzer> I double checked and to me it shows us as subscribed
[13:43] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/postgresql-12/+subscriptions
[13:43] <cpaelzer> I'm never sure who can see subscriptions on these pages, but at least I see ours
[13:44] <doko> hmm, and some binaries were already in main, somebody must have demoted stuff ...
=== ricab|lunch is now known as ricab
[13:49] <cpaelzer> doko: auto-demoted or manually?
[13:49] <cpaelzer> I got no ping or FYI
[13:49] <cpaelzer> ahasenack: did you get anything about PG related deomtions going on as part of the transition?
[13:49] <ahasenack> no
[13:50]  * ahasenack doing online training
[13:52] <doko> cpaelzer: while you are here, could you look at the asyncpg test failures during the build?
[13:52] <cpaelzer> doko: I have looked at that last week and myon uploded the changes we need
[13:52] <cpaelzer> doko: it probably needs custom test triggers to build against the right versions
[13:53] <cpaelzer> doko: I was away up until today, I'll look again what todays status is
[13:56] <doko> ta
[14:50] <cpaelzer> doko: the old asyncpg FTBFS is resolved as planned, but now crashes into something new
[14:50] <cpaelzer> doko: I will continue checking this, but it will tkae more time just so you know
[14:51] <cpaelzer> it has a lot of errors around python object streams being unexpectedly garbage collected
[14:51] <cpaelzer> but I'm not sure yet it is symptom or the reason for the new FTFBS
[14:51] <cpaelzer> I updated the bug so that anyone else looking at it is aware
[14:52] <doko> ta
[15:00] <vorlon> jibel: don't block on me
[15:02] <jibel> vorlon, k, thanks
[15:31] <rafaeldtinoco> cpaelzer: sbd bad tests passed, corosync migrated fyio
[15:48] <cpaelzer> rafaeldtinoco: so my retry did resolve it
[15:48] <cpaelzer> rafaeldtinoco: well, we still don't know what it was, but I'm glad it migrated now
[15:48] <cpaelzer> rafaeldtinoco: thanks for open-vm-tools btw
[15:48] <cpaelzer> uploaded for SRUs
[15:51] <rafaeldtinoco> cool
[16:09] <cpaelzer> ahasenack: btw on postgres I did some custom test triggers with the right components together and as you have seen doko did the promotion - I'll recheck tomorrow once time passed to run these tests
[16:23] <seb128> do we have a vcs for console-setup?
[16:23] <seb128> the source has Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/console-setup/ubuntu
[16:23] <seb128> but that didn't get updated since 2016...
[16:23] <seb128> cyphermox, rbalint, vorlon, ^ you might know since you did recent uploads?
[16:28] <vorlon> zeb
[16:28] <vorlon> seb128: if I uploaded and didn't update the listed repo, it's because it was already stale when I looked; and if the VCS isn't there, I don't know where one is
[16:30] <seb128> k, same as me then
[16:30] <seb128> thx, I will probably do the same (or maybe I should just remove the Vcs-Bzr reference since it's obviously buggy)
[16:49] <rbasak> rbalint: o/ in bug 1849679, did you "Run the autopktest in a WSL environment where the user name contains space"? From your screenshot it looks like all the user names are "ubuntu"?
[16:49] <ubottu> bug 1849679 in wslu (Ubuntu Eoan) "[SRU] Please backport 2.3.2-0ubuntu2 to supported releases" [Undecided,Fix committed] https://launchpad.net/bugs/1849679
[17:01] <rbalint> rbasak, the Windows user name had space
[17:02] <rbalint> i think it is visible at least on one of the screenshots
[17:03] <rbasak> OK no problem thanks
[17:03] <rbasak> I don't require it to be visible in a screenshot, just wanted to make sure it hadn't been accidentally missed :)
[17:10] <rbalint> rbasak, i appreciate that :)
[18:19] <ahasenack> Skuggen: hi, have you seen this mysql error, on an upgrade from 5.7 to 8? https://pastebin.ubuntu.com/p/94YMBxTz2B/
[18:22] <ahasenack> query_cache_limit: Do not cache results that are bigger than this. Removed in MySQL 8.0.3.
[18:22] <ahasenack> hmm
[18:29] <ahasenack> wondering if postinst should handle that, like it handles some other upgrade paths
[20:01] <teward> I think I found a cdbs bug/issue heh...
[20:01] <teward> or namely, Eickmeyer discovered the issue with some of the Studio package builds, I just noticed the headache more deeply.
[20:01] <teward> (and I don't use cdbs so I need someone fluent in that to check my assumptions)
[20:08] <teward> namely, the cdbs debhelper rules for inclusion refer to  dh_systemd_enable but for debian compat >= 11 it is supposed to be using dh_installsystemd (which is not defined in the CDBS rules/scripts it seems in the .mk rules files)
[21:16] <infinity> teward: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885407
[21:16] <ubottu> Debian bug 885407 in cdbs "debhelper class broken in compat level 11 (dh_systemd_enable deprecated)" [Important,Open]
[21:17] <infinity> teward: Given the age of that bug, I'd read it as "stop using cdbs".
[21:17] <teward> infinity: seems to me like CDBS should be consider deprecated
[21:17] <infinity> teward: But in the short term, "use compat 10" also works.
[21:17] <teward> Eickmeyer: ^ read above
[21:17] <teward> same for you tsimonq2
[21:18] <teward> infinity: considering this is for a new/updated package version of hydrogen for the Studio team, do we have a problem with compat 10 in the interim until the package is fully DH and not CDBS functional?
[21:18] <Eickmeyer> teward: ack. Will reduce compat to 10.
[21:18] <teward> ... that came out as a weirdly syntax-failing string
[21:19] <tsimonq2> teward: Why does anyone even use that?
[21:19] <teward> tsimonq2: ask Debian
[21:19] <teward> regarding hydrogen
[21:19] <Eickmeyer> tsimonq2: In this case, probably just legacy.
[21:19] <teward> on another note
[21:19] <teward> ***read your darn messages for once**
[21:19] <tsimonq2> teward: No.
[21:19] <tsimonq2> :P
[21:21] <teward> Eickmeyer: until such time as you/simon/debian has time to remove CDBS from the equation in the package I'd fall back to compat 10 as infinity indicated
[21:21] <teward> *for now*
[21:21] <Eickmeyer> teward: ack
[21:21] <teward> infinity: might we be able to run a report to see exactly how many packages are using CDBS as their build environment?  Just out of pure curiosity
[21:21] <infinity> teward: "Why does anyone use cdbs?" -- Inertia.  It was there before dh(1) style debhelper, and it eased many people's burdens for repetitive tasks of similar packages (the entirety of GNOME was CDBS, for instance), but once something clearly better came along (dh(1)), some people gobbled it right up, some people never found the time or motivation to switch.
[21:21] <infinity> And some of us still have packages that use neither.
[21:21] <infinity> And some of us still have a package that contains the prototype for what became CDBS....
[21:22] <infinity> teward: grep '^Build-Depends.*cdbs' /var/lib/apt/lists/*Sources?
[21:22] <tsimonq2> infinity: Next mission after Qt 4 is gone? :P
[21:23] <tsimonq2> ...is it still even maintained?
[21:23] <infinity> cdbs maintenance seems to be light.  It gets uploads, but they're hardly exciting.
[21:23] <infinity> I think considering it deprecated and trying to move people off it is The Right Thing, but it should be done in Debian.
[21:24] <teward> *yikes* 2155 packages
[21:24] <infinity> Gratuitous Ubuntu deltas to switch build systems would be worse than doing nothing.
[21:24] <teward> have it as a build-dep
[21:25] <tsimonq2> infinity: Fair.
[21:25] <tsimonq2> K can start with the orphaned packages. :P
[21:26] <tsimonq2> *I
[21:26] <teward> you mean your face?  :P  *shot*
[21:26] <infinity> teward: So, yeah, "yikes", but also keep in mind that cdbs and dh were solving the same problem for most packages (how do I avoid doing packaging?), so many of those 2k packages might be veeeery simple to convert in a matter of seconds, or with a scrpt.
[21:26] <teward> true
[21:26] <teward> infinity: or many of those packages are old, obsolete, and orphaned and can be purged
[21:26] <teward> most of the ones I see here in ths output are Universe
[21:26] <infinity> teward: As in, if they don't do anything fancy in cdbs, they also probably don't need fancy in dh overrides, and can just be replaced with the dh 1-liner.
[21:27] <teward> infinity: do we maintain an Ubuntu specific variant of Lintian for Ubuntu-specific things?
[21:27] <teward> just curious
[21:28] <infinity> Nope.
[21:28] <teward> hmm
[21:28] <teward> maybe Debian can update lintian to include a warning in there about CDBS being a build dependency and not working with compat > 10
[21:29] <infinity> If you consider 2 years of non activity on that bug as concensus that CDBS isn't meant to work with compat >> 10, that might be a reasonable check.  I dunno.
[21:29] <infinity> Also, did you try compat 12 too, or was it specifically 11 that failed?
[21:30] <teward> Eickmeyer: ^
[21:30] <infinity> Cause the debhelper manpage itself warns against using 11 because it does Weird Things with systemd.
[21:30] <Eickmeyer> infinity: It was >=11 that was being indicated.
[21:30] <Eickmeyer> infinity: That said, I only used 11.
[21:30] <Eickmeyer> infinity: I suppose if it's in Focal only that I could go 12.
[21:31] <infinity> I mean, CDBS might also hate 12 too.
[21:31] <Eickmeyer> For safety sake, probably 10 would be best.
[21:31] <infinity> I just know that 11 is called out by debhelper as being evil and wrong, specifically because of dh_installsystemd, and should be avoided.
[21:31] <infinity> Even without CDBS in the mix.
[21:34] <teward> infinity: will I have to ask the Debian governance teams to decide about CDBS throwing lintian warnings, or will just filing a bug against Lintian work?  I forget how Debian governs crap at that level
[21:38] <infinity> teward: Just filing a lintian bug, pointing at the CDBS bug will be a good start.  They may push back with "lintian isn't meant to be a source for documenting bugs in other packages", but I think given the situation, you can argue for why it's not a terrible check.
[21:39] <infinity> teward: I'd also love a lintian warning of "CDBS is deprecated crap, please switch to dh(1)", but without the CDBS maintainers agreeing that, that one might need a tech-ctte decision. :P
[21:39] <infinity> s/agreeing that/agreeing to that/
[21:39] <teward> i'm quite tempted to send a message to tech-ctte to ask them to consider CDBS deprecated in favor of DH due to this major bug
[21:39] <teward> so that in Debian POlicy latest versions it's defined as "CDBS is not supported"
[21:40] <teward> but that's my opinion and i have no gauge on debian-devel yet on this
[21:40] <teward> so that's a later task :p
[21:40] <infinity> teward: A mail to debian-policy, CC to devel, along the lines of "should we consider CDBS deprecated" might start a fun flame war, if you're bored.
[21:40] <teward> hah
[21:41] <teward> *spoofs the origin email to be infinity's @ubuntu.com address then lets hell loose*
[21:41] <infinity> (Or it might prove entirely non-contentious, it's hard to predict these things)
[21:41] <teward> :P
[21:41] <teward> yeah that's on my "Later" list
[21:42] <teward> i've got some more important things on my radar, esp. for this dev cycle constantly tracking nginx mainline upstream and updating focal xD
[21:42] <teward> 'cause it's That Time Again (TM)
[21:43] <infinity> teward: I don't think one bug is enough to deprecate a tool used by thousands of packages.  But there are other arguments to be made about ease of use, easing third-party contributions, standardising, etc, etc.
[21:44] <infinity> Back when I started, all but the most complex packages had nearly identical dh_make rules files.  They were a bit messy, but if you'd seen one, you know how they all worked.
[21:44] <infinity> dh(1) offers that, but much simpler, and it's definitely mind-bending when you run into something that breaks from that standard.
[21:44] <teward> infinity: Indeed, but if 90% of packages with cdbs are written for deb policy earlier than ${LATEST} then they aren't updated for the standard anyways so in *theory* they wouldn't get completely purged
[21:45] <teward> the DH incompatibility alone here should be enough to make it an RC blocker for most packages
[21:45] <teward> at least, IMO
[21:45] <teward> s/most packages/most packages reliant on CDBS with compat >> 10)
[21:45] <teward> BAH i can't type to save my life >.<
[21:46] <teward> blocked from testing maybe, but...
[21:46] <teward> considering I know little to nothing about CDBS any email I write will need extra eyes (such as yours) before being sent
[21:47] <teward> and I'm still busy wioth Ubuntu level of policy things (Backports comes to mind!) and am working with others on those things first
[21:47] <teward> and I"m hesitant to suggest a radical policy change in Debian without backup xD
[23:09] <teward> infinity: lintian maintainers NACK'd on the statement people will see FTBFS first.
[23:09] <teward> infinity: so perhaps this should be a policy decision
[23:09] <teward> (i'll have to email debian-policy, cc -devel, and ask them their opinions/thoughts)
[23:21] <fred909> do the packages in the base deb repo for a release (like xenial) ever get updated or are all updates pushed to xenial-security or xenial-updates?
[23:22] <teward> fred909: to my knowledge, all 'updates' get pushed to -updates, except in the case of security updates which get pushed to -security and -updates, and kernel updates which also get pushed to -security and -updates
[23:22] <teward> and the base 'xenial' repositories don't really change much at all
[23:22] <fred909> teward: thanks :)
[23:42] <fred909> aaah apparently -updates are moved into the main repo after awhile...
[23:43] <fred909> makes creating deterministic Docker images difficult. debian has https://snapshot.debian.org/