[10:39] <Laney> dear BTS, please give bug numbers faster
[10:41] <Unit193> 3
[11:24] <cpaelzer> sil2100: (for +1 maint) xnox (for boost in general): is one of you on src:mrs which is a FTFBS blocking boost1.71 (and thereby ICU as well)
[11:24] <cpaelzer> seems it was ignroed and removed in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957567
[11:25] <cpaelzer> I was wondering if anyone looks already into that - and if not what you'd think for Ubuntu (removal as well, or trying to fix) would be the better approach
[11:25] <cpaelzer> I can give it some time to fix FTFBS and if it seems to complex file a removal  (as part of +1 duty), but wanted to avoid that this is already being worked on
[11:36] <cpaelzer> different question - I know if we have a source in Ubuntu the only way to prevent auto-sync from Debian is giving it a ubuntuX suffix. But if we don't have the src:package is there a way somewhere to block a given package from syncing?
[11:36] <cpaelzer> I'd want to check for a particular package if it is blocked there as well (and hopefully find a comment about the reasons)
[11:41] <cjwatson> cpaelzer: Are you thinking of https://code.launchpad.net/~ubuntu-archive/+junk/sync-blacklist ?
[11:41] <cpaelzer> sounds about right cjwatson - thanks
[11:41] <cpaelzer> I'll take a look there
[11:44] <cpaelzer> thanks that was it
[11:44] <cpaelzer> I knew such a thing existed, I even see changes in there by me - but I forgot the right paths to look at
[13:11] <xnox> cpaelzer:  what do you mean "blocking boost1.71"?
[13:12] <xnox> cpaelzer:  there is no boost transitions in progress.
[13:12] <seb128> xnox, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#boost1.71 ?
[13:13] <slyon> Hey core-devs! Could somebody please review/sponsor my fix for bug #1889138 (debdiff attached) – so I can move forward with getting sbuild/dpkg migrated from -proposed?
[13:13] <xnox> seb128:  but that's not a transition, it is simply part of icu transition.
[13:13] <seb128> xnox, sorry I don't have the start of the discussion, but that's boost in proposed blocked by some items
[13:14] <seb128> so 'blocking' seems to apply
[13:15] <xnox> ok
[13:15] <juliank> Laney: I guess we can't teach britney to always add a grub2-signed trigger when it has a grub2 trigger (and vice versa)
[13:17] <seb128> xnox, reading irclog nobody said 'transition', I think saying boost is blocked in proposed due to mrs (and dart) was factual?
[13:25] <cpaelzer> xnox: yes what seb128 referenced is what I meant
[13:25] <cpaelzer> not a boost transition itself
[13:27] <cpaelzer> xnox: and the bug - as written in the description - is intentionally not (yet) an RM bug
[13:27] <cpaelzer> giving it a chance to be fixed and only then it becomes an RM
[13:34] <xnox> ok
[13:36] <xnox> cpaelzer:  i have separate questions about libvirt/virsh. I'm trying to write a restart tool. And when doing `systemctl restart libvirtd.service` it only restarts the main daemon, not any other processes it spawned due to KillMode=process"
[13:36] <xnox> cpaelzer:  so i'm working, is it safe to kill/restart the dnsmasq agents that are running under virsh? is there something like virsh net-restart command?
[13:36] <xnox> not working => so i'm wondering
[13:36] <xnox> or if restarting dnsmasq is not safe.
[13:37] <cpaelzer> xnox: no net-restart
[13:37] <cpaelzer> xnox: not that I know of
[13:37] <cpaelzer> xnox: you'd need to destroy + start
[13:38] <cpaelzer> xnox: if that is safe depends on the complexity of the network that you defined
[13:40] <cpaelzer> most of the time it is not safe (with guests up=
[13:41] <cpaelzer> xnox: the default net for example includes the definition of virbr0 - if you remove/start that guests likely will have connection issues
[13:41] <cpaelzer> xnox: but other configurations e.g. for existing bridges might have no issue at all
[13:43] <cpaelzer> xnox: this was discussed upstream a while ago btw https://bugzilla.redhat.com/show_bug.cgi?id=1597326
[13:43] <Laney> juliank: feels possible, would be best if we can do it in an upstreamable way
[13:44] <cpaelzer> xnox: how about "virsh net-update" - does that give you waht you need
[13:45] <cpaelzer> xnox: https://wiki.libvirt.org/page/Networking#Applying_modifications_to_the_network
[13:59] <xnox> cpaelzer:  it would, if it allowd "empty" updates. It tries to force me to actual make a change.
[13:59] <xnox> i.e. sudo virsh net-update --help
[14:00] <xnox> sudo virsh net-update --network vlan --command modify --xml '' --section ''
[14:00] <xnox> is not ok, because section & xml cannot be empty
[14:00] <xnox> =(
[14:02] <xnox> i kind of want to "just reexec dnsmasq" please
[14:08] <ahasenack> hi vorlon, about my question from friday about the corner case of user removing /etc/default/motd-news before upgrading to the new packages (which would reinstall that config file), did you get a change to think about it?
[14:10] <ahasenack> https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/388835/comments/1022886
[14:11] <ahasenack> apologies if you did and my  irc proxy bot was offline
[17:05] <realtime-neil> Does launchpad support the kind of pipeline that will host source, build source, and publish the resulting debian package(s)? If so, where can I learn more about this?
[17:06] <tumbleweed> realtime-neil: https://help.launchpad.net/Packaging/SourceBuilds
[17:08] <realtime-neil> tumbleweed: much thanks
[17:19] <rbasak> Anyone else with an XPS 9360 getting wifi lockups after suspend/resume, requiring reboot? I found a newer firmware than in linux-firmware. Trying that now.
[17:44] <realtime-neil> tumbleweed: is there a way to get launchpad to build things git-hosted elsewhere?
[17:44] <ahasenack> for recipes, the git repo needs to reside in lp afaik
[17:44] <ahasenack> you can setup a mirror, though
[17:45] <realtime-neil> ahasenack: how do I set up a mirror?
[17:45] <ahasenack> you have to create a project, then in the "code" tab you can setup a mirror I believe
[17:46] <realtime-neil> I tried to mirror https://github.com/torvalds/linux.git and got "This foreign branch URL is already specified for the imported repository ~lopin/linux/+git/linux."
[17:47] <ahasenack> are you lopin?
[17:47] <realtime-neil> I am not
[17:47] <ahasenack> then I don't know, sorry
[17:47] <realtime-neil> okay, thanks anyway
[17:49] <tumbleweed> looks like that import is timing out
[17:49] <tumbleweed> You can talk to the launchpad people about that, but I'm guessing the repo is simply too big
[17:53] <cjwatson> Kernel packaging tends to be rather too complicated to work well with fully-automated recipes anyway.
[18:13] <ricotz> rbalint, hi, is systemd 246-2ubuntu1 in groovy-proposed going to transition as it is?
[18:15] <ricotz> I upgraded to it last week and my system nearly dead-locked due to some high cpu usage in the upgrade itself and on the following restart, which rendered the system unusable
[18:16] <ricotz> downgraded to 245.7-1ubuntu1 again
[18:49] <ottok> Hi! I am a Debian developer trying to learn how to backport packages in Ubuntu. I followed docs and filed https://bugs.launchpad.net/bionic-backports/+bug/1873597 a month ago but there was no response. What shall I do next?
[18:53] <rbasak> ottok: unfortunately the backports process is mostly dead and there's no longer an active backports review team. Some background here: https://lists.ubuntu.com/archives/ubuntu-devel/2019-January/040575.html
[18:53] <rbasak> And continuation here
[18:53] <rbasak> https://lists.ubuntu.com/archives/ubuntu-devel/2019-February/040587.html
[18:55] <rbasak> I am in favour of its resurrection, FWIW. But it needs a committed team to drive process and resume reviews I think.
[18:55] <rbasak> teward: FYI ^
[18:59] <ottok> Thanks, skimmed through those emails, but it left it hanging in the air on what should be done now. Shall I send email to ubuntu-backports@ or just give up?
[18:59] <sarnold> rbasak: is there a way to give ottok backports priviliges "soon"? ie at the next dmb meeting or something? this is the most effort / activity I've seen put towards backports in ages, and ottok's surely demonstrated an ability and commitment
[19:00] <rbasak> sarnold: I'm in favour but it's not up to the DMB currently - the DMB isn't delegated management of the backports team currently
[19:00] <sarnold> rbasak: oh :( :( :(
[19:01] <rbasak> But separately, IMHO we need a reviewer for ottok's work as well as ottok himself contributing the upload
[19:01] <sil2100> !dmb-ping
[19:02] <rbasak> I think requiring backports _reviewers_ to be core dev or MOTU is probably appropriate
[19:03] <rbasak> And we need volunteers for that
[19:03] <rbasak> teward was such a volunteer in the past, but I'm not sure that he's still available
[19:03] <rbasak> Unfortunately review work is generally tedious and thankless, so few people volunteer
[19:05] <rbasak> ottok: maybe reply to the ubuntu-devel@ thread pointing out that you are volunteering a backport but have no reviewer? I think that'd be the most useful place to direct an email.
[19:05] <sarnold> rbasak: yeah, reviewers would definitely be nice -- and full ack on it being all work no play
[19:51] <teward> rbasak: sarnold: Laney and I Had also written up restrictions that it needs someone dedicated to maintain the backport
[19:51] <teward> sort of how you need a DM or be a Sponsored Maintainer in debian to upload for a given package
[19:51] <sarnold> teward: I can appreciate the sentiment but that's more than universe packages get now ..
[19:51] <teward> but chaos happened with COVID and everything so I haven't pursuded it much
[19:51] <teward> sarnold: well 'exceptions' exist :P
[19:52] <teward> but the problem with backports is "anyone can request"
[19:52] <sarnold> hah, yes, but no one actually bothers doing them -- until today, anyway ;)
[19:52] <teward> if we restrict that to devs are teh only ones who can file the request that solves that, the problem is backports is overwlelmed with crap
[19:52] <teward> and things that aren't good candidates, aren't tested, etc.
[19:53] <teward> but i'm currently recovering in the hospital
[19:53] <teward> so E:NOACTION from me for a few days
[19:53] <teward> appendicitis ia a pain
[19:53] <teward> but we caught it early now I'm just needing to relax and recover for a couple days
[19:54] <teward> sarnold: what's on the radar about the backport?
[19:54] <teward> s/about the/for/
[19:54] <teward> in this case
[19:55] <sarnold> teward: oh ugh :/ I hope you're back home soon :)
[19:56] <teward> sarnold: also backports requires coredev/MOTU I THINK to upload to -backports directly without sponsoring
[19:56] <sarnold> teward: in this case, ottok's trying to get this going https://bugs.launchpad.net/bionic-backports/+bug/1873597
[19:56] <teward> I can upload to -backports for example
[19:56] <teward> for Universe or Main or {ANY} because coredev
[19:56] <teward> but it needs approved/released regardless
[19:56] <teward> C D and E are dead righgt?
[19:57] <teward> C D E series*
[20:00] <teward> ottok: yeah, so
[20:00] <teward> backports process in terms of review is heavily stalled
[20:00] <teward> if not dead
[20:00] <teward> Laney's the only one who does backport reviews and has wanted things backported only that make sense
[20:00] <teward> what's your justification for needing it backported?  (just curious)
[20:01] <teward> rbasak: what's the status of mariadb in Xenial
[20:01] <teward> or is it nonexistent?
[20:01] <teward> they say in their backport bug that: Ubuntu Bionic has currently only galera-3 available. The new version galera-4 is required to run MariaDB 10.4 or newer.
[20:02] <teward> and unless people are using MariaDB 10.4+ on Xenial i'm *real* hesitant to do the second part of the backport which is a Xenial request
[20:03] <rbasak> teward: I would need to look. ottok will be more familiar with all that
[20:03] <teward> ok
[20:03] <teward> ottok: ^ same questions
[20:03] <teward> i assume they went AFK/AWOL
[20:03] <teward> rbasak: maraiadb 10.0 is in Xenial
[20:11] <teward> so the jump from 10.0 to 10.4 i'm not entirely sure why is needed/substantial
[20:12] <teward> if it's "just so we can use newer MariaDB" i'm... not entirely willing to review/sponsor for Xenial.
[20:34] <ottok> I noticed that there is also a user request to backport a package I maintain in Debian and already maintain backport in PPA: https://bugs.launchpad.net/bionic-backports/+bug/1876599
[20:34] <ottok> I promise to make the review very easy, since the backports are all no-changes backports and live along identical ones in Debian backports.
[20:35] <ottok> And I have a track record of maintaining my packages in both Debian and Ubuntu (unless an idividual package/pocket had some special case going on)
[20:37] <sarnold> teward: ^^
[20:43] <ottok> teward: I replied to your "review questions" on Launchpad in context.
[20:43] <ottok> teward: https://bugs.launchpad.net/bionic-backports/+bug/1873597
[21:30] <teward> ottok: i assume galera-3 and galera-4 are coinstallable then?
[21:30] <teward> or do they conflict?
[21:33] <teward> ottok: also: > Using the Ubuntu backported Galera 4 package would assure a good quality of packaging instead of using any alternative option,
[21:33] <teward> if and only if you also backport mariadb 10.4+ into the repos as well
[21:34] <teward> because mariadb isn't backported - so unless someone picks up MariaDB 10.4+ and backports it, adding the dependent library doesn't really seem like a necessary/useful step, *especially* since backports it not default-installable unless you specify it during apt calls or are installing things from -backports
[21:37] <teward> because any 'third party repository', PPA Upstream or Otherwise, would require (1) backports to be enabled, and (2) still be third party so vetting the mariadb code is still 'hard' (as sarnold and others on the sec team can admit to from experience)
[21:37] <teward> ottok: do you or someone else have the intent to also backport MariaDB 10.4+ into Bionic Backports as well?
[21:42] <teward> (posted to the bug as followup as well as my REJECT review for Xenial - xenial dies in the next year and MOST people are probably upgraded except for legacy applications, and I don't have any viable tests of whether MariaDB newer can actually *run* on Xenial so I have no basis for accept.
[21:43] <teward> Laney: if I get up off my lazy butt and backport NGINX, would you be willing to back me up on that backport to Bionic of the stable in focal-updates?
[23:08] <realtime-neil> How do I tell my launchpad recipe to checkout a git tag and not a git branch?
[23:11] <cjwatson> realtime-neil: What does your recipe look like at the moment?
[23:11] <realtime-neil> ```
[23:12] <realtime-neil> # git-build-recipe format 0.4 deb-version {debupstream}-0~{revtime}
[23:12] <realtime-neil> lp:test9001 v4.16
[23:12] <cjwatson> That ought to work, except that the lp:test9001 code import failed
[23:12] <cjwatson> And https://launchpadlibrarian.net/492765364/realtime-neil-test9001-+git-linux.log is somewhat unclear
[23:13] <cjwatson> Miiiiiight be helped by https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/373732 but I'm really not sure
[23:14] <realtime-neil> cjwatson: I feel like you're suggesting something but I'm too ignorant to understand.
[23:15] <cjwatson> I'm suggesting that this is broken right now
[23:15] <cjwatson> And it's not completely clear how to fix it
[23:15] <cjwatson> Your recipe syntax is correct in and of itself, but that doesn't help when https://code.launchpad.net/~realtime-robotics/test9001/+git/linux contains no branches
[23:16] <cjwatson> (or tags)
[23:17] <realtime-neil> cjwatson: if I have a fresh source repository that might still be syncing from an upstream source, would that explain the lack of branches and tags?
[23:17] <cjwatson> What fresh source repository exactly are you talking about?
[23:18] <cjwatson> (URL)
[23:18] <realtime-neil> cjwatson: I have a fork of github.com/torvalds/linux here: https://gitlab.com/realtime-robotics/linux
[23:19] <cjwatson> Whether that gitlab repository is still syncing from upstream is immaterial
[23:19] <cjwatson> This is a bug in Launchpad code imports that affects a small number of very large repositories
[23:19] <cjwatson> Probably the same as the tail-end of https://bugs.launchpad.net/launchpad/+bug/1642699
[23:20] <cjwatson> Need to get one of my colleagues to review my merge proposal above so we can see if it helps
[23:20] <realtime-neil> ah, okay; you're theorizing that, since this repository is so big, I might be hitting the bug you mentioned
[23:20] <cjwatson> It may not be precisely the same thing, but it's something along those sorts of lines
[23:21] <cjwatson> You can see the code import failure in the log above
[23:25] <cjwatson> The problem is that it spends five minutes without producing any output at all, which causes the code import monitor to assume it's got stuck and kill it
[23:25] <cjwatson> (I think it's five minutes anyway)
[23:26] <realtime-neil> cjwatson: okay, understood; how would you suggest I proceed? Smaller repository? Maybe try this with just a shallow copy of what I care about most?
[23:27] <cjwatson> The purpose of my branch above is to crank up the progress output so that we get some kind of output every so often to pacify the watchdog, but to throttle it so it doesn't produce an absurd amount of noise in the log
[23:28] <cjwatson> You could try a smaller repository, or you could try pushing it manually to Launchpad rather than using a code import
[23:28] <realtime-neil> lemme try the latter
[23:28] <cjwatson> "Smaller" may possibly be mainly "fewer refs"