[10:31] <jamespage> coreycb, icey: I focussed on package bugs this morning for my triage slot - pushed new's down to 130
[10:31] <jamespage> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=ubuntu-openstack&field.component-empty-marker=1&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.
[10:31] <jamespage> used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
[12:53] <cpaelzer> athos: FYI I reordered the bug housekeeping entries as requested
[12:53] <cpaelzer> athos: 61% done atm, still on track IMHO
[12:53] <cpaelzer> thanks for the suggestion
[12:53] <athos> thanks, cpaelzer :)
[13:14] <ahasenack> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1950321 was just set to "confirmed" because more people clicked "this affects me", does this status change affect the MIR workflow?
[13:15] <ahasenack> it also was assigned to security already...?
[13:15] <ahasenack> oh, n/m
[13:15] <cpaelzer> thanks for the ping
[13:15] <ahasenack> about security, I mean
[13:16] <cpaelzer> sure, that asssignment correct - and the state is ok as well
[13:16] <ahasenack> this is one of the early MIRs
[13:16] <cpaelzer> in any "pre-decision" states New/Confirmed is equal
[13:16] <cpaelzer> See https://wiki.ubuntu.com/MainInclusionProcess?action=show&redirect=MIRTeam#Process_states
[13:18] <cpaelzer> It is good to see that people "still" want this, as we had requests in the past but also a discussion like "is this still wnated/needed in 2022"
[13:18] <cpaelzer> people still marking this as importent for them confirms that this didn't change
[13:19] <ahasenack> I even got a ping in the glusterfs slack server, saying "hey, so finally this bug XXXXX will be fixed? :)"
[13:19] <ahasenack> it was about samba using gluster
[13:19] <cpaelzer> yeah we have a few packages in main that could enable glusterfs backends then
[13:19] <ahasenack> that bug, to be honest, we can fix even if the mir doesn't go through. Just put the gluster vfs module in a separate package in universe. IT will increase the delta with debian, though
[13:20] <cpaelzer> we want/need it in main anyway, so (now that we can) let us enable it without extra complexity
[14:55] <coreycb> jamespage: awesome, thanks!!
[17:28] <smoser> dannf: https://code.launchpad.net/~smoser/ubuntu/+source/sbuild-launchpad-chroot/+git/sbuild-launchpad-chroot/+merge/414681 
[17:28] <smoser> could you take a look at that sometime >
[17:28] <smoser> (you are last-touched), so that is why you have the priviledge of being bothered by me today.
[17:30] <dannf> smoser: sure :)
[17:54] <paride> interesting how that's the only git repo under lp:~motu
[19:55] <ahasenack> any idea what license would cover this script? https://src.fedoraproject.org/rpms/nfs-utils/blob/rawhide/f/nfsconvert.py
[20:00] <sarnold> https://src.fedoraproject.org/rpms/nfs-utils/blob/rawhide/f/nfs-utils.spec#_46
[20:01] <sarnold> if I'm reading this spec correctly, the libnfsidmap binary package is licensed bsd, the rest appear to inherit that "MIT and GPLv2 and GPLv2+ and BSD" blob..
[20:01] <sarnold> and this script is in the nfsv4-client-utils binary package
[20:04] <ahasenack> but it's not in the upstream source
[20:04] <ahasenack> it was added by the packager
[20:04] <ahasenack> even though they are the same person in this case :/
[20:04] <ahasenack> confusing
[20:05] <sarnold> so confusing
[20:05] <ahasenack> I'm working on updating nfs-utils, and the new (aham, since 2016 or so) version uses one config file now, instead of /etc/sysconfig/ (RH) or /etc/default/nfs-* (deb/ubu), and if you just upgrade, your options from /etc/default will just be ignored
[20:05] <ahasenack> fedora has this conversion script they wrote
[20:05] <ahasenack> which is handy
[20:06] <ahasenack> and I'm patching locally to use in ubuntu, to see how far I get
[20:06] <ahasenack> but the licensing question will come up, specially if/when I send this to debian
[20:06] <sarnold> yeah, my guess here won't stand up to FTP NEW :)
[20:08] <ahasenack> why new?
[20:08] <ahasenack> I mean, same packages, just version bump (ok, there are details like soname change which makes it a new package, but still)
[20:09] <ahasenack> if adopting this, it would be in debian/*
[20:09] <ahasenack> I could also perhaps ask upstream to incorporate that script, but they last changed it in  2019
[20:10] <ahasenack> (in the rpm package)
[20:11] <ahasenack> plan B is to write one from scratch
[20:11] <ahasenack> plan C is to just detect if the config was changed by the user, and issue a warning asking the user to alter the new config manually (but nobody reads those)
[20:11] <ahasenack> let's see how far I get
[20:14] <bryceh> whew, down to 1 package blocking php-defaults from transitioning...
[20:24] <ahasenack> just one, really? wow
[20:25] <bryceh> yeah but it's symfony, which has been a challenge all cycle
[20:27] <bryceh> I think I could write a book on resolving circular dependencies after this...  ugh
[20:49] <Odd_Bloke> If only you'd had that book _before_ having to deal with all of these dependencies
[20:52] <ahasenack> it's like that xkcd graph it takes X number of times doing it before you (automate|write a book about) it
[21:06] <bryceh> I do find it humorous when I google for a problem, and the one thing that pops up is some bug or wiki entry I'd made last time I ran into it
[21:08] <sarnold> heh, I've run into my own SO answers before..
[21:13] <patdk-lap> more fun when you get a ticket update 7years later, won't fix, lucid release
[21:13] <ahasenack> s/release/EOL/
[21:13] <patdk-lap> wait that wasl ike 10 or 11 years
[21:13] <patdk-lap> well ya, but I only got the notice like 3months ago :)
[22:37] <bryceh> symfony 5.4.2 finally built successfully 
[22:38] <bryceh> crossing fingers that its autopkgtests pass...
[23:43] <bryceh> √ https://autopkgtest.ubuntu.com/packages/s/symfony/jammy/armhf
[23:44] <sarnold> quick run away before it breaks again!
[23:45] <bryceh> heh no kidding
[23:46] <bryceh> I think php-defaults should migrate now, maybe next Britney run