=== guiverc2 is now known as guiverc === tmhoang5 is now known as tmhoang === antoine3 is now known as antoine [11:11] cpaelzer, hey, I just saw bug #1912168. The proper process to suggest rls review for a team is usually to tag rls--incoming and not directly target (especially without assignee) [11:11] bug 1912168 in ppp (Ubuntu Groovy) "please merge ppp 2.4.9 for 21.04 and then consider ipv6 default fix for SRU" [Undecided,New] https://launchpad.net/bugs/1912168 [11:12] seb128: s/a team/some teams/ - e.g. these tags wouldn't mean anything for the server team [11:12] seb128: good to know you follow the same as foundations [11:12] seb128: have you added that already or should I? [11:13] cpaelzer, historically it was a workflow common to all 'distro' team, it's a suboptimal that server doesn't follow it ... do you guys have another way to flag issues for your team to consider? [11:13] seb128: we triage all bugs of the packages we are susbcribed to [11:13] no need to tag anything specially [11:14] well, sometime the importance is up for interpretation [11:14] there is still value imho in others being able to flag an issue they would like to propose for SRU or rls targetting [11:14] (as you just did there by adding the targetted lines) [11:15] I added the tag to the case [11:15] thanks for the discussion [11:15] thx, sorry I was about to type a reply to that [11:16] at least I leant that server was not follow the same process ;-) [11:16] And in regard to our bug handling, if you add a tag or comment we will still see and think about it - all I'm saying is that our handling/triage isn't limited to those with a particular tag like this one [11:17] right [11:19] cpaelzer, glancing over the server section on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-incoming-bug-tasks.html there are a bunch of server ones that got tagged and not triaged, e.g https://bugs.launchpad.net/ubuntu/+source/drac/+bug/1897292 since septembre [11:19] Launchpad bug 1897292 in drac (Ubuntu) "drac ftbfs in groovy" [High,Confirmed] [11:21] rbasak: we should later check how/why those slipped triage ^^ [11:22] thx [11:37] was focal updated to the 5.8 kernel serie? (wondering due to bug 1910982) [11:37] bug 1910982 in usb-modeswitch (Ubuntu) "ZTE Modem USB stick not recognized with kernel 5.8" [Undecided,New] https://launchpad.net/bugs/1910982 === ebarretto__ is now known as ebarretto [12:36] cpaelzer: I wouldn't consider those sorts of bugs within scope for our triage process anyway, though I don't know if that's the reason or if was something else. [12:37] Also drac is in universe in Groovy? [12:38] scope> because I'd consider work coming from FTBFS reports to be its own work item that gets prioritised as a whole, as opposed to handling piecemeal reports from bug reports that may or may not get filed [12:38] s/FTBFS reports/the regular rebuild testing/ === TJ- is now known as Guest77993 === TJ_Remix is now known as TJ- [14:47] anyone else just get unsubscribed from the TB's list? [14:49] Yep, being discussed in ~is on MM [14:50] ok thanks, I'll assume I'm going to be put back :-) [14:50] Seems like the new CC got access to it and maybe thought it was meant to be a TB-members-only list or something? [14:51] ah yes, I got a couple of emails that explain more [14:51] seems like a bit of shoot first, ask questions later [14:51] Just a bit === _hc[m] is now known as _hc === ijohnson is now known as ijohnsonlunch === ijohnsonlunch is now known as ijohnson|lunch === ijohnson|lunch is now known as ijohnson [18:55] hi everyone [18:57] how is it used by apt/aptitude the string passed with target release argument (eg: apt upgrade -s -t hirsute) [18:59] I was having a look at the apt source code, but I was not able to find the way that argument is used [19:01] I tried also with apt-cache, and it seems that something like `-t hirsute` is similar to `-t n=hirsute` instead of `-t a=hirsute` === tianon is now known as tianon-- === tianon- is now known as tianon