[00:47] <bazhang> Id be very surprised if the r7 240 worked with fglrx
[01:59] <ModelEngine> i need to speak with an operator, can someone pls pm me? thx
[02:00] <Unit193> Please state the nature of your request, and someone may be with you presently.
[02:01] <ModelEngine> I apparently seem to be pissing ppl off in the channel, but I have no idea why or how, as I seem to be following all the rules
[02:03] <ModelEngine> http://imgur.com/jkzT6uQ  http://imgur.com/u5ZaHa6  http://imgur.com/sUE8OX7
[02:03] <ModelEngine> those are the reason for this question. please see the replies to my questions from user: daftykins
[02:05] <ModelEngine> as you can see from the transcript, dafty seems to be upset about something, however I have NO idea why or for what reason I am condescended
[02:06] <ModelEngine> I thought #ubuntu is where beginners like me can feel safe to ask questions without getting snapped at. If that is not the purpose of #ubuntu, please state the purpose
[02:08] <ModelEngine> Unit193: can you help me with this?
[02:11] <ModelEngine> would anyone be around to help?
[02:19] <ModelEngine> is there someone here who would be available to explain to me the policies, procedures and protocols associated with chatting in #ubuntu?
[02:23] <ModelEngine> My mistake, I had thought that #ubuntu ops was there as a sort of moderator, but I guess not.
[02:24] <pleia2> ModelEngine: please be patient, someone familiar with #ubuntu will have to help you out
[02:24] <pleia2> !guidelines
[02:25] <pleia2> but you can start there if you're looking for policies and things ^^
[02:26] <ModelEngine> pleia2: thanks, I'm reading the EULA or w/e its called right now to find out what appropriate channel behavior is, and I will def wait for an answer, thank you!
[02:29] <ModelEngine> while reading this: https://wiki.ubuntu.com/IRC/Guidelines i have found numerous examples of how not to treat a noob, as well as examples on how to be polite when asking a question. Good to know. I'm learning and want to learn more, I just need ppl who are willing to be patient with me
[02:37] <ModelEngine> pleia2: i asked at 19:00, and it is now 19:36, it appears to be a bad time (i.e., busy, etc) would it be better if I just emailed my issue to the irc ppl?
[02:38] <pleia2> ModelEngine: if you can't stick around I'd suggest coming back later (there isn't really a dispute resolution email aside from the council, and you don't need their help at this point)
[02:39] <ModelEngine> can you tell me if it is standard procedure to condescend a noob when he is asking a question? cuz if it is, obviously i joined the wrong channel
[02:41] <ModelEngine> i feel like cuz daftykins is a reg contributer, that everyone is just gonna try to sweep this under the rug. I was always under the understanding that the ubuntu community encourages new people to join and get involved. As a new user on ubuntu, geting snapped at for asking a question doesn't make me feel very welcome or interested in joining this 'community'
[02:42] <pleia2> I won't speak in such generalities, the incident in question is best discussed with someone familiar with the situation
[02:42] <ModelEngine> pleia2: ok, that's cool. i do appreciate your speakign with me tho
[02:42] <pleia2> you're welcome :) I hope you find what you're looking for
[02:43] <ModelEngine> thanks :) if you the community is anythign like you, then obviously i just stumbled upon a bad apple. I hope that this is the case.
[02:43] <ModelEngine> a bad apple with dafty, i mean
[02:56] <daftykins> hey ModelEngine
[02:56] <daftykins> can someone get rid of this troll?
[02:57] <ModelEngine> hey dafty, i have proof of you violating the TOS of the IRC
[02:57] <daftykins> no you don't :)
[02:59] <ModelEngine> well, we'll just wait for an op now won't we?
[03:00] <daftykins> honestly you really should find better things to do with your life than create drama in IRC on a Friday night
[03:02] <daftykins> phunyguy: so it seems ModelEngine has gotten the wrong end of the stick here and has a bit of a hard on for me now
[03:02] <daftykins> i really don't have a clue what's going on
[03:02] <phunyguy> ModelEngine: an op is here now.  Let's talk.
[03:03] <ModelEngine> just act stupid,dafty
[03:03] <ModelEngine> who is the op?
[03:03] <phunyguy> <---
[03:03] <phunyguy> One of them anyway.
[03:03] <ModelEngine> cool, lets have a discusiion, shall we
[03:03] <ModelEngine> ok, so, phunyguy is the OP, so i have something to tell you
[03:04] <phunyguy> I am going to read backscroll in #ubuntu as well, I would just appreciate a few minutes do to that.
[03:04] <ModelEngine> i will pastebin it, and imgur it so it doesn't flood the channel
[03:04] <phunyguy> to do*
[03:04] <ModelEngine> for sure
[03:05] <ModelEngine> phunyguy: here is the pastebin: http://pastebin.com/8YDAaZb7
[03:06] <ModelEngine> phunyguy: here is the screenshots of daftykins condescending me and treating me like garbage:http://imgur.com/jkzT6uQ  http://imgur.com/u5ZaHa6  http://imgur.com/sUE8OX7
[03:06] <phunyguy> I think we just have a good old misunderstanding here.
[03:06] <phunyguy> I read the backscroll.
[03:06] <ModelEngine> i need 2 minutes
[03:06] <daftykins> yeah i think ModelEngine got a bit offended by me linking to the !manual
[03:07] <daftykins> and has decided to cause all this drama because of it
[03:07] <phunyguy> let's just calm down, and try to get along.  I see no malicious intent on either side, and it escalated.
[03:07] <daftykins> well i actually see some trolling right here with the intent to ruin my rep to other new users joining
[03:07] <phunyguy> remember we are all volunteers... even the ops.
[03:07] <ModelEngine> phunyguy: did you read all of dafty's harrassing comments meant to piss me off? he was very antagonizing
[03:07] <daftykins> so it depends whether ModelEngine will agree to let it go and move on.
[03:08] <daftykins> ModelEngine: you're making it up.
[03:08] <phunyguy> I am asking you both to drop it.
[03:08] <ModelEngine> phunyguy: do you see that he won't even acknoledge that he was condescending, rude, and antaagonizing?
[03:08] <ModelEngine> phunyguy: will  you hear me out?
[03:08] <phunyguy> no.
[03:08] <phunyguy> I have heard enough.
[03:08] <ModelEngine> i haven't even explained it to you
[03:09] <phunyguy> Sure you have.
[03:09] <phunyguy> and I read the backscroll.
[03:09] <ModelEngine> i am a new user here, and i just wanted someone to patiently explain something, but dafty could do nothing but condescend me and treat me unfairly. he is experienced, and i am not. I thought ubuntu was a community where peopole could feel safe to ask questions. is it not?
[03:10] <daftykins> tell me which line i was being condescending in?
[03:10] <ModelEngine> oh now you care
[03:10] <daftykins> because i really have no idea what you're talking about :)
[03:10] <ModelEngine> phunyguy: ?
[03:10] <daftykins> sigh such a timewaster
[03:10] <Unit193> David-A: Heya, need help with anything?
[03:10] <ModelEngine> see, comments like that, don't make others feel very good, dafty
[03:11] <daftykins> and nor should it, you are trolling.
[03:11] <ModelEngine> phunyguy: do you see even a bit how dafty is being condescending and treating others (especially new ppl to ubuntu) unfairly?
[03:11] <daftykins> you have yet to paste a line because you know you're making it up :)
[03:12] <ModelEngine> I will paste a line right now, hang on a sec: \
[03:12] <David-A> Unit193: no, just watching how the dispute that started in #ubuntu is working out
[03:12] <Unit193> David-A: Please no rubber necking.
[03:12] <phunyguy> David-A: please part the channel
[03:12] <phunyguy> see /topic
[03:12] <David-A> ok
[03:13] <phunyguy> ModelEngine and daftykins, we have heard both sides.  Our job here isn't to punish users, it is to keep order in the channels.  I need you both to agree to disagree here.
[03:13] <daftykins> i'm happy to move on :)
[03:13] <phunyguy> that's 1.
[03:15] <phunyguy> ModelEngine?
[03:15] <ModelEngine> can I be assured that I won't be condescended (made to feel stupid) when I have a question that I need someone to be patient in explaining, because I am not an expert on ubuntu, but am a new user looking to start out in a friendly 'community'?
[03:15] <phunyguy> ModelEngine: that is between you and daftykins to hash out outside of the channels.
[03:15] <ModelEngine> and how do i do that? he's on the other side of the world!
[03:16] <ModelEngine> but, yes, i will move on
[03:16] <phunyguy> ModelEngine: Private message.
[03:16] <ModelEngine> oic
[03:16] <phunyguy> Like I said, we are all volunteers here, and it is not our job to punish.
[03:16] <ModelEngine> ok, i will steer clear of dafty if he steers clear of me and doesn't intentionally try to make me look stupid
[03:16] <ModelEngine> to other in the channel
[03:16] <phunyguy> All support in these channels is given on a volunteer basis, and that needs to be remembered.
[03:17] <ModelEngine> i know, but when i ask a question, i expect to be treated like a human being not a pile of poop
[03:17] <phunyguy> THank you for your understanding.
[03:17] <ModelEngine> phunyguy: thank you for hearing me out, i appreciate being respected
[03:17] <phunyguy> No problem :)
[03:18] <ModelEngine> i feel much better now, have a good day :)
[03:18] <phunyguy> Please remember that further escalation in the channels will result in further action
[03:18] <ModelEngine> how would you recommend that i escalate it?
[03:18] <phunyguy> ModelEngine: the ignore button works wonders
[03:18] <ModelEngine> cool, since i'm new, can you pls tell me where to find it?
[03:18] <phunyguy> that depends on the client.
[03:18] <ModelEngine> hexchat
[03:19] <phunyguy> and that is beyond the scope of this channel.
[03:19] <phunyguy> there is an ignore button in your brain, use that for now.
[03:19] <ModelEngine> ok thats alright. have a good day and thank you for your help
[03:19] <ModelEngine> lol :) thanks
[03:19] <ModelEngine> bye bye
[03:19] <phunyguy> cya.
[03:19] <daftykins> o/
[05:12] <BlackPower> Y YU RACEST ASS CRAKKERS BAN ME?
[05:12] <BlackPower> STUPID BITCH
[05:13] <tonyyarusso> I think you just answered your own question there.
[05:14] <BlackPower> BITCH YU RACEST ND STUPID ASS HELL WYTE MOFUCKA
[05:14] <BlackPower> KKK BITCH
[05:14] <tonyyarusso> Yeah, that sort of language is never allowed in the Ubuntu channels.    Thank you for your attention to detail
[09:34] <ikonia> ?
[09:34] <gshmu1> forward message
[09:35] <ikonia> gshmu1: do you need anything from the ubuntu operator team or are you trying to get ubuntu support
[09:35] <gshmu1> this is a bug!  i confirm it at web...
[09:36] <ikonia> gshmu1: so you're looking for ubuntu support ?
[09:36] <gshmu1> no, but i want fix this bug
[09:37] <ikonia> ok - then this is the wrong channel
[09:37] <ikonia> if you don't need anything from the ubuntu operators please /part this channel
[16:29] <bazhang> LMNOP_, dont idle here
[16:50] <Unit193> ubottu is on a break, need another?
[18:14] <DJones> Anybody with access to ubottu? Currently MIA
[18:24] <DJones> tsimpson: See above
[18:29] <Unit193> I have my clone if you need one *right now*, until then.
[18:30] <DJones> Its been missing for about 4 hrs
[18:30] <Unit193> I put ubot93 in #x* #l and studio.
[18:31] <DJones> I'd be happy with that until tsimpson cam re-enable ubottu
[18:32] <Unit193> DOne.
[18:33] <DJones> Thanks
[20:31] <ikonia> ls/win 4


[08:15] <Razva> good mornin' folks. why in the world is MAAS running...two DHCP servers...?
[08:19] <Razva> should I use 14.04 LTS for Ubuntu Cloud Images? or 15.10?
[08:35] <haasn> Razva: ps aux | grep dhcp | curl -sF "file=@-" https://0x0.st
[08:35] <Razva> mornin' haasn
[08:36] <Razva> https://0x0.st/X0i.txt
[08:36] <Razva> haasn at this point I've reinstalled Ubuntu
[08:36] <Razva> just a sec to setup networking
[08:37] <haasn> well that machine is clearly running 0 DHCP servers :p
[08:37] <Razva> yup, right now yes
[08:38] <Razva> can you please take a look at https://github.com/Razva/newbadmin/blob/master/firewall/nat.sh ?
[08:38] <Razva> it's a script one of the good folks here provided for NAT
[08:38] <Razva> I've slighly modified it
[08:38] <Razva> looks ok?
[08:38] <Razva> (for NAT)
[08:51] <haasn> Razva: seems reasonable, not sure if the MASQUERADE line would benefit from an extra -i "$INTIF" or not but if it works it works
[08:53] <Razva> any idea how to retain this after reboot...? :|
[08:54] <haasn> Razva: iptables-save and iptables-restore can be used to save the current settings to a file (and do the opposite). Most distros provide some sort of init script for automatically doing that
[08:55] <Razva> got it
[08:56] <Razva> haasn: https://0x0.st/X0K.txt < that ps aux you've requested
[08:56] <Razva> seems that only MAAS is running, right?
[08:56] <haasn> seems to only be running one
[08:57] <haasn> on interface enp0s25 (this is your private interface, I take it?)
[08:57] <Razva> weird, last time it was i*something-dhcp-server running also... :|
[08:57] <Razva> exactly, it's the lan
[08:57] <Razva> now, let's try to PXE boot
[08:57] <haasn> Razva: when stuff like that happens it's a good idea to look at the -f option, in this case /var/lib/maas/dhcpd.conf
[08:57] <haasn> If that's /etc/dhcp/dhcpd.conf or something like that then it's probably some “default” system-wide dhcpd service running accidentally
[08:57] <Razva> do you recommend 14 LTS or 15, for Ubuntu Cloud?
[08:58] <haasn> I have no idea. I use 14 LTS because I haven't had a reason to change
[08:59] <Razva> does Liberty works with 14?
[09:00] <Razva> yup, it successfully booted, no idea why last time it basically started two DHCP servers...it was a fresh install...
[10:14] <Razva> haasn except "Allow SSH access and prevent machine from powering off", should I check the other two boxes?
[10:14] <Razva> Retain network & Retain storage?
[10:15] <haasn> What those checkboxes mean is that if you're commissioning a node that you've already comissioned in the past, any storage/network configuration you made manually will be preserved instead of reset back to the default
[10:15] <haasn> If this is your first time commissioning that node they do nothing
[10:15] <Razva> aaand if I didn't ever commisioned them...I suppose that I should just "SSH and prevent machine from powering off", right?
[10:17] <haasn> I don't see any reason to set that unless you're trying to debug something that went wrong
[10:18] <Razva> yay, ok
[10:19] <Razva> the only "wrong" thing until now is that MAAS is seeing "power on" even if the machine is 100% powered off :|
[10:20] <Razva> any idea why>
[10:21] <haasn> Razva: the power status is not checked all the time but polled at regular intervals (every few minutes), you can click ‘check now’ to force an update
[10:21] <Razva> haasn did it 3 times, they still point as being on
[10:21] <Razva>  Checking power -> Power on
[10:21] <haasn> Razva: What power type?
[10:22] <Razva> even tried to "shutdown" them from MAAS
[10:24] <Razva> IPMI. they are Dell servers
[10:25] <haasn> Razva: try asking ipmipower -D LAN_2_0 -h HOST -u maas -p PASS --stat what it thinks of your host
[10:26] <Razva> 	Power State	OFF
[10:26] <Razva> haasn any idea what's the pass? :))
[10:27] <haasn> Razva: you can check in the maas GUI
[10:27] <haasn> It should have created a new account/password when enlisting
[10:27] <haasn> If ipmipower works but MAAS does not, seems like a bug to me
[10:27] <Razva> got it, just a sec to see
[10:28] <Razva> HOST = IP or host.maas ?
[10:28] <haasn> It should be the same hostname as in the maas power configuration
[10:29] <Razva> paltry-cave < who in the world is generating these names? :)
[10:30] <Razva> <IP_ADDRESS>: connection timeout
[10:31] <Razva> interesting.
[10:36] <haasn> Razva: you could also try logging in via SSH
[10:38] <Razva> I'm power cycling both machines, see what's the result
[10:39] <Razva> long live iDRAC :)
[10:39] <Razva> the machines are not even commisioned, so I cannot really SSH in...
[10:40] <Razva> oook both are not booting via PXE
[10:42] <Razva> ssh key bla bla...
[10:43] <Razva> both are waiting here: http://screencast.com/t/LvFwpbHIaBnK
[10:43] <Razva> ^ is that "normal"?
[10:44] <Razva> aaaand they seem to be stuck at that point :|
[10:50] <haasn> Razva: SSH to the service processor (IPMI interface), not the host OS
[10:54] <Razva> SSH seems to be working, but I cannot login
[10:57] <haasn> Razva: with the maas username/password?
[10:58] <haasn> what about root?
[11:02] <Razva> haasn yup, with the maas u/p, I cannot login
[11:02] <Razva> I'll try to login with root now
[11:02] <Razva> <IP_ADDRESS>: connection timeout < from ipmipower
[11:03] <Razva><EMAIL_ADDRESS>password: < ssh works
[11:03] <Razva> /admin1-> < root worked
[11:03] <Razva> any hints now? :D
[11:12] <haasn> Razva: set the root un/pw in maas and be done with it? :p
[11:13] <haasn> oh, connection timeout from ipmipower with root p/w too?
[11:13] <haasn> Razva: try ipmitool -I lanplus -U root -P ... -H ... user list
[11:14] <haasn> If ssh works but ipmipower does not, then you might need to specify a firmware-specific workaround flag (via -W)
[11:14] <haasn> e.g. I need -W sun20 for some of my old sun servers
[11:17] <Razva> haasn exactly
[11:17] <Razva> haasn but I cannot even reset IPMI
[11:18] <Razva> ipmitool -H <IP_ADDRESS> mc reset warm
[11:18] <Razva> Password:
[11:18] <Razva> Error: Unable to establish LAN session
[11:18] <haasn> did you try the ipmitool command I suggested?
[11:18] <Razva> nope, just a sec
[11:19] <Razva> ipmitool -I lanplus -U root -H -H <IP_ADDRESS> user list
[11:19] <Razva> Password:
[11:19] <Razva> Address lookup for -H failed
[11:19] <Razva> Could not open socket
[11:20] <Razva> (same with minus the extra -H)
[11:20] <Razva> ipmitool -I lanplus -U root -H <IP_ADDRESS> user list
[11:20] <Razva> Password:
[11:20] <Razva> Error: Unable to establish IPMI v2 / RMCP+ session
[11:21] <Razva> but I can SSH login...
[11:21] <Razva> sh<EMAIL_ADDRESS>[11:21] <Razva><EMAIL_ADDRESS>password:
[11:21] <Razva> /admin1->
[11:26] <haasn> Razva: maybe something here will help? https://www.gnu.org/software/freeipmi/freeipmi-bugs-issues-and-workarounds.txt
[11:27] <haasn> also see man ipmipower (scroll down to workarounds)
[11:31] <Razva> I've contacted the data-center...maybe they can do a power-cycle/reset...
[11:31] <haasn> doubt it will help
[11:36] <Razva> its their server, so I should be able to list users...at least.
[16:52] <Razva> hey guys. I have no idea why but maas refuses to interpret the right status from IPMI...
[16:52] <Razva> the server is powered down, I can see that via DRAC and console..
[16:52] <Razva> but still maas reports the server as being online. any hints...?
[17:23] <redelmann> hi, im having some trubles with unmanaged networks
[17:23] <redelmann> im trying to let my local dhcp and dns to manage this network
[17:24] <redelmann> but for some reason /etc/resolv.conf is setting maas ip address as DNS
[17:24] <redelmann> i double check my local dhcp setting and everything seems fine
[17:25] <redelmann> so, why maas is putting herself as DNS of an unmanaged network?
[17:28] <Razva> redelmann no idea, but that's what maas does (at least on my setup)
[17:30] <redelmann> Razva, ok, thank. It little strange, i was supposing that unmanaged network is UNmanaged :P
[17:30] <redelmann> Razva, i think juju bootstrap fail in my setup because of this
[17:40] <Razva> redelmann I have a very weird issue. MAAS reports power on, even if power is off (I can see in iDRAC that power is off, and console shows No power)
[17:41] <redelmann> Razva, it's that for me?
[17:42] <Razva> redelmann yes
[17:42] <Razva> maybe you have any ideas...
[17:43] <redelmann> Razva, noup.
[17:43] <redelmann> Razva, im playing with maas for 2 weeks to now
[17:44] <redelmann> Razva, so im not the most indicated person
[17:44] <Razva> haha, I'm playing for ehm...2 days :D
[17:44] <Razva> I've successfully setup 3 machines, everything PXE boots, but this single darn machine doesn't wants to boot....
[17:45] <Razva> or whatever...boots but doesn't wants to report power as it should
[17:45] <redelmann> Razva, maybe hardware problem?
[17:46] <Razva> no idea...
[17:46] <Razva> do you use IPMI or...?
[17:46] <redelmann> IPMI and virsh
[17:47] <redelmann> i'am mixing virtual nodes with intel hardware
[17:47] <Razva> I have only intel / Dell hardware, but no idea why the heck I cannot control it...
[17:47] <redelmann> im just testing maas for a full implementation
[17:48] <Razva> well...I didn't had any issues with it until now, only problem was that - at first install - Ubuntu installed a separate DHCP server as well. no idea why, but a clean install solved everything
[17:49] <Razva> Power on < I'm gonna kill somebody.
[17:49] <redelmann> Razva, you are installing MAAS from apt?
[17:49] <Razva> the server is off god damnit...
[17:50] <redelmann> Razva, try with "check now" link :P
[17:50] <redelmann> Razva, or manually power on the server
[17:50] <Razva> yeah if I manually power on it works, but this is not the way to do it...
[17:50] <redelmann> Razva, after manually power on, swith to off with maas
[17:51] <Razva> how...?
[17:51] <Razva> I cannot manually set power off in maas
[17:51] <redelmann> Razva, i know but maybe yoy can "sync" what maas think about node and rearl node state
[17:51] <Razva> please do me a favor
[17:51] <redelmann> Razva, take action -> power off?
[17:52] <Razva> ipmipower -D LAN_2_0 -h SOME-IPMI-IP -u root -p THE-ROOT-PASSWORD --stat
[17:52] <Razva> does it works for you?
[17:55] <redelmann> Razva, im in home rigth know.
[17:55] <redelmann> Razva, i dont know why cant ssh to cluster
[17:56] <redelmann> Razva, give me a second
[17:57] <redelmann> Razva, but usually thats the command i use to check the whole cluster power status without problem
[17:58] <redelmann> Razva, i never use -D, only -h ip
[18:01] <redelmann> Razva, did you try with --debug?
[18:01] <Razva> well...what command do you use, usually?
[18:03] <Razva> (ipmipower_powercmd.c, _retry_packets, 1214): host = <IP_ADDRESS>; p = 1; Sending retry, retry count=24
[18:09] <Razva> redelmann are you deploying OpenStack or just MaaS?
[18:09] <redelmann> Razva, just MAAS
[18:09] <redelmann> Razva, ipmipower -h ip -u root -p THE-ROOT-PASSWORD --stat
[18:09] <redelmann> Razva, i let ipmipower to decide ipmi version
[18:10] <Razva> <IP_ADDRESS>: connection timeout
[18:10] <Razva> but the interesting thing is that I can ssh to it
[18:11] <Razva> /admin1->
[18:12] <redelmann> Razva, ipmipower --version?
[18:13] <redelmann> Razva, some old ipmipower utilitis had a bug with -p options i think
[18:14] <Razva> redelmann via SSH?
[18:14] <redelmann> Razva, no, just ipmipower --version in machine you are trying to connect
[18:15] <redelmann> Razva, maas server i suppose
[18:15] <Razva> ipmipower - 1.1.5
[18:16] <Razva> you?
[18:16] <redelmann> Razva, look at this: https://lists.gnu.org/archive/html/freeipmi-users/2005-11/msg00018.html
[18:17] <redelmann> Razva, its old
[18:17] <redelmann> Razva, forget about it, ipmipower 0.1.3 its the problem
[18:18] <redelmann> Razva, ipmipower - 1.1.5
[18:18] <roaksoax> Razva: do you have logs from /var/log/maas/ , it is probably telling why it cannot connect  to IPMI
[18:18] <roaksoax> if that's the case
[18:20] <roaksoax> redelmann: maas doens't really support external DHCP/DNS anymore. But eventhen, MAAS is the defautl DNS server unless you set it differently for each subnet
[18:21] <redelmann> Razva, did you try ipmiping <IP>
[18:22] <redelmann> roaksoax, http://paste.ubuntu.com/15060537/
[18:22] <redelmann> roaksoax, i set DNS on my maas-eth0
[18:22] <roaksoax> redelmann: what version of MAAs are you using?
[18:22] <redelmann> roaksoax, it's that no enough?
[18:23] <roaksoax> 1.9
[18:23] <redelmann> roaksoax, 1.9
[18:23] <redelmann> roaksoax, it's testing purpose
[18:23] <roaksoax> redelmann: right, so when you deploy, is the interface of the machine configured to do what? DHCP ?
[18:24] <redelmann> roaksoax, exactly
[18:24] <roaksoax> redelmann: right, so DHCP should be setting the DNS server right?
[18:24] <redelmann> roaksoax, rigth
[18:24] <roaksoax> redelmann: also, can you get the curtin config ?
[18:26] <roaksoax> redelmann:  maas <session> node get-curtin-config <system-id>
[18:26] <redelmann> roaksoax, ohh THANK, i was losing my head
[18:28] <redelmann> roaksoax, http://paste.ubuntu.com/15060721/
[18:29] <redelmann> roaksoax, /etc/resolv.conf contain: <IP_ADDRESS> (my lan DNS) and <IP_ADDRESS> (my mass server lan ip)
[18:30] <redelmann> roaksoax, i was expecting to have only <IP_ADDRESS>
[18:30] <roaksoax> redelmann: Yeah I see. is the NIC on your system connected to 'maas-eth0' subnet ?
[18:31] <roaksoax> redelmann: i think the problem here is that since MAAS is not configure eth0, it is ont telling /etc/network/interfaces to set the DNS of maas-eth0
[18:32] <roaksoax> redelmann: eitherway DHC{P should be setting it
[18:32] <roaksoax> and it doesn't seem like it is ?
[18:33] <redelmann> roaksoax, maas server and node have a NIC on 'maas-eth0'
[18:33] <roaksoax> redelmann: right, but MAAS is not managing DHCP/DNS< and my *guess* is that because of that, DNS server of maas-eth0 is not being set
[18:33] <roaksoax> redelmann: on the config
[18:35] <redelmann> roaksoax, that's rigth
[18:35] <redelmann> right
[18:35] <roaksoax> redelmann: so, yif you could file a bug, I'll discuss it with my guys and see if we can fix that
[18:36] <roaksoax> cause I think we porbably should
[18:37] <roaksoax> redelmann: please attach both, the maas-eth0 subnet and the curtin config
[18:37] <roaksoax> to the bug report
[18:37] <redelmann> roaksoax, great, between my poor English and my mass-newby it's hard to explain. i will do my best
[18:37] <redelmann> roaksoax, ok
[18:38] <roaksoax> redelmann: don't worry, just file it, and I'll fix the wording if need by
[18:38] <roaksoax> be*
[19:23] <redelmann> roaksoax, https://bugs.launchpad.net/maas/+bug/1545500
[19:24] <redelmann> roaksoax, hope you can understand the whole idea/problem :P
[19:26] <redelmann> roaksoax, thank for you
[19:26] <redelmann> roaksoax, thank for your time
[19:43] <mup> Bug #1545500 opened: MAAS unmanaged network set wrong DNS information <MAAS:New> <https://launchpad.net/bugs/1545500>
[21:56] <haasn> Hopefully somebody reads this: If you're thinking of managing maas hosts with juju, use ansible instead! My life is so much happier and it's easier to set up, maintain and interact with :)
[22:12] <stormmore> somehow I don’t see juju bootstrap being that difficult a command to use


[03:20] -queuebot:#ubuntu-release- New binary: rustc [s390x] (hirsute-proposed/universe) [1.44.1+dfsg1+llvm-3ubuntu1] (i386-whitelist)
[03:56] -queuebot:#ubuntu-release- New binary: rustc [i386] (hirsute-proposed/universe) [1.44.1+dfsg1+llvm-3ubuntu1] (i386-whitelist)
[04:04] -queuebot:#ubuntu-release- New binary: rustc [amd64] (hirsute-proposed/universe) [1.44.1+dfsg1+llvm-3ubuntu1] (i386-whitelist)
[04:07] -queuebot:#ubuntu-release- New binary: rustc [ppc64el] (hirsute-proposed/universe) [1.44.1+dfsg1+llvm-3ubuntu1] (i386-whitelist)
[05:24] -queuebot:#ubuntu-release- New binary: telepathy-haze [amd64] (hirsute-proposed/none) [0.8.0-3] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: telepathy-haze [ppc64el] (hirsute-proposed/none) [0.8.0-3] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: telepathy-haze [arm64] (hirsute-proposed/universe) [0.8.0-3] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: telepathy-haze [armhf] (hirsute-proposed/universe) [0.8.0-3] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: telepathy-haze [s390x] (hirsute-proposed/universe) [0.8.0-3] (no packageset)
[05:41] -queuebot:#ubuntu-release- New binary: telepathy-haze [riscv64] (hirsute-proposed/universe) [0.8.0-3] (no packageset)
[06:13] <vorlon> https://autopkgtest.ubuntu.com/packages/r/rust-proc-macro2/hirsute/s390x ugh, '@', what a terrible name for a test
[07:36] -queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[07:36] -queuebot:#ubuntu-release- Unapproved: update-notifier (groovy-proposed/main) [3.192.34 => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[07:36] -queuebot:#ubuntu-release- Unapproved: update-notifier (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[07:36] -queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.11 => 3.168.12] (ubuntu-desktop, ubuntu-server)
[08:43] -queuebot:#ubuntu-release- New binary: rustc [armhf] (hirsute-proposed/universe) [1.44.1+dfsg1+llvm-3ubuntu1] (i386-whitelist)
[09:11] -queuebot:#ubuntu-release- Unapproved: borgbackup (xenial-proposed/universe) [1.0.12-0ubuntu<IP_ADDRESS> => 1.0.13-0ubuntu<IP_ADDRESS>] (no packageset)
[09:13] -queuebot:#ubuntu-release- Unapproved: borgbackup (bionic-proposed/universe) [1.1.5-1 => 1.1.14-2ubuntu<IP_ADDRESS>] (no packageset)
[09:14] -queuebot:#ubuntu-release- Unapproved: borgbackup (focal-proposed/universe) [1.1.11-5 => 1.1.14-2ubuntu<IP_ADDRESS>] (no packageset)
[09:15] <LocutusOfBorg> they superseeds previous versions ^^ I added a testcase to the code to show regressions on the fixed bug
[10:02] -queuebot:#ubuntu-release- New binary: rustc [arm64] (hirsute-proposed/universe) [1.44.1+dfsg1+llvm-3ubuntu1] (i386-whitelist)
 vorlon, ahh, and now entangled with re2 and perl
[10:03] <doko> wake up, these are entangled from the start
[10:03] <doko> but there appears to be a britney bug that it is only shown now:
[10:03] <doko> Issues preventing migration:
[10:03] <doko> Implicit dependency: python3-defaults libsbml (not considered)
[10:04] <doko> this didn't show up before, only now
[10:21] <cpaelzer> doko: FYI I've seen a few more perl blocks and resolved former blocking autopkgtest of libpod-2-docbook-perl and netatalk (which blocked openldap which in turn blocked perl).
[10:21] <cpaelzer> Of these netatalk will stay broken (due to Debian changes in 3.1.12~ds-5), might need a test reset maybe?
[10:21] <cpaelzer> doko: sil2100: and thanks for the skip hint on postgresql-12!
[10:21] <cpaelzer> In addition the custom triggers I submitted yesterday also cut down the remaining issues from ~25 to 5 which leaves less of a bad feeling.
[10:23] <doko> cpaelzer: afk until Monday, please get in touch with vorlon and rbalint
[10:41] <RikMills> doko: I asked Laney about that excuses weirdness a few weeks ago. not sure if it is fixable IIRC
[10:42] <RikMills> https://irclogs.ubuntu.com/2020/11/09/%23ubuntu-release.html#t16:05
[10:48] <Laney> it depends what happened, someone would need to analyse the situation properly
[10:50] <Laney> btw, some proposed-migration improvements coming soon via Debian
[10:50] <Laney> improvements when adding extra triggers, don't pick ones already in the release pocket (thanks juliank)
[10:51] <Laney> don't queue tests for transitions until the rdep is installable again
[10:52] <Laney> that last one is still being reviewed
[10:56] <rbalint> cpaelzer, plusone i'm on unblocking perl
[10:57] <cpaelzer> rbalint: what is left actually? Only some autopkgtest on perl itself  think right - are you working on those?
[10:58] <rbalint> cpaelzer, and mariadb, which i'm filing a hint for
[10:58] <cpaelzer> +1 on that
[10:58] <rbalint> cpaelzer, LP: #1906628
[10:58] <cpaelzer> rbasak: ^^ FYI
[10:58] -queuebot:#ubuntu-release- Unapproved: backport-iwlwifi-dkms (focal-proposed/universe) [8324-0ubuntu3~20.04.1 => 8324-0ubuntu3~20.04.2] (no packageset)
[10:58] <rbalint> cpaelzer, it may need to be run on a big vm, i'm testing that
[10:59] <cpaelzer> I hope that https://release.debian.org/transitions/html/auto-openssl.html doesn't reach us before perl is over - that would be even more entanglement
[11:07] <rbalint> ubuntu-release could you please merge https://code.launchpad.net/~rbalint/britney/+git/hints-ubuntu/+merge/394803 to let mariadb 10.5 in?
[11:08] <rbalint> cpaelzer,, if mariadb-10.5 migrates can we drop mariadb-10.3 from release?
[11:19] <cpaelzer> AFAIK yes, rbasak would be the expert to answer in case there is a hidden detail
[11:21] <rbalint> cpaelzer, thanks, then there is only a little left for perl, fingers crossed to get the custom triggered tests through quickly
[11:22] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (focal-proposed) [2.664.10]
[11:25] <cpaelzer> you have my crossed fingers as well ...
[11:25] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.8 => 2.664.10] (desktop-core, i386-whitelist)
[11:35] <rbalint> ubuntu-archive please act on LP: #1906640 to unblock perl
[11:38] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (groovy-proposed) [6.1.16-dfsg-4~ubuntu<IP_ADDRESS>]
[11:40] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (groovy-proposed) [6.1.16-1~ubuntu<IP_ADDRESS>]
[11:44] <sil2100> rbalint: on it
[11:46] <doko> already done
[11:46] <rbalint> the hint is still left
[11:47] <Laney> The hint is wrong
[11:47] <Laney> It should be mariadb-10.3
[11:47] <Laney> rbalint:
[11:47] <rbalint> Laney, no, I'd like to let 10.5 in
[11:48] <Laney> I know
[11:48] <Laney> But you're resetting the wrong test.
[11:48] <Laney> autopkgtest for mariadb-10.3/1:10.3.25-0ubuntu1: amd64: Regression ♻ , arm64: Pass, armhf: Pass, i386: Ignored failure, ppc64el: Pass, s390x: Pass
[11:48] <rbalint> true, fixing
[11:48] <Laney> fwiw, this regression does reproduce for me, so this hint is only OK IMHO if mariadb-10.3 is going to be removed, so please check with rbalint
[11:48] <Laney> rbasak*
[11:50] <rbalint> Laney, you mean it is failing for you locally
[11:50] <rbalint> ?
[11:50] <Laney> yes
[11:50] <Laney> with 10.5 from proposed and it passes without that (release pocket only)(
[11:50] <Laney> same test failing as the log
[11:51] <Laney> but if 10.3 is going away, it's OK to not care I think
[11:51] <rbalint> Laney, how do you trigger it?
[11:52] <rbalint> Laney, just being curious, i'd like to have the hint :-)
[11:54] <rbalint> i've fixed the hint btw
[11:55] <Laney> autopkgtest --timeout-copy=6000 --shell-fail --apt-upgrade --apt-pocket=proposed=src:mariadb-10.5 mariadb-10.3 -- qemu --ram-size=1592 autopkgtest-hirsute-amd64.img
[11:56] <rbalint> Laney, thanks, trying to repro here
[11:56] <rbalint> Laney, i tried with even less ram, but it made more tests to fail
[11:58] <rbalint> Laney, according to cpaelzer 10.3 will go away with 10.5 migrating, but still waiting for rbasak's confirmation
[11:58] <Laney> ack
[12:13] <rbalint> Laney, passes with --ram-size=4096 fails with --ram-size=1592 here
[12:19] <rbalint> Laney, is it enough for the hint? rbasak may not be around to give his advice
[12:21] <rbalint> Laney, sil2100 https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/394808
[12:24] <Laney> rbalint: I get it, the tests come from mariadb-test-data and it's a new test with 10.5
[12:24] <Laney> big feels better
[12:24] <Laney> let's try that
[12:26]  * Laney adds to the right config file :p
[12:28] <rbalint> Laney, ok, retriggering the tests then
[12:28] <rbalint> Laney, could you please also add the hint?
[12:29] <rbalint> Laney, i don't want to miss the next britney run
[12:33] <RikMills> rbalint: mariadb-10.3 src is to be removed soon?
[12:33] <RikMills> oh, cpaelzer I mean. sorry
[12:34]  * RikMills will need to switch akoandi depends
[12:34] <cpaelzer> RikMills: well, the talk above was based on assumptions and we wanted to wait for rbasak to confirm/deny
[12:34] <cpaelzer> RikMills: also as you know "soon" can in those terms sometimes mean in 3 months
[12:35] <RikMills> indeed! lol
[12:35] <cpaelzer> and since I have no current insight into that transition it is hard to make a reliable statement
[12:35] <cpaelzer> rbalint: test wise mysql-8.0 (the closest sibling to mariadb) already has the big-package hint
[12:36] <cpaelzer> rbalint: that IMHO is another argument for hinting the bigtest for mariadb
[12:37] <Laney> rbalint: I'm watching it, I will make sure the next run sees the pass
[12:43] <Laney> rbalint: there you go, it passed before the previous one finished even
[12:51] <rbasak> o/
[12:51] <rbasak> Otto is planning a switch in mysql-defaults for 10.3->10.5 soon. It's already in VCS
[12:51] <rbasak> However I'm not sure when he's planning to remove 10.3.
[12:54] <LocutusOfBorg> looks like a perl package is failing, but maybe this is a launchpad sadness?
[12:54] <LocutusOfBorg> https://launchpadlibrarian.net/509667382/buildlog_ubuntu-hirsute-s390x.libcbor-xs-perl_1.82-1_BUILDING.txt.gz
[12:54] <LocutusOfBorg>     (result, consumed) = self._buffer_decode(data, self.errors, final)
[12:54] <LocutusOfBorg> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfc in position 36: invalid start byte
[12:55] <rbalint> LocutusOfBorg, saved the log and retried, let's see
[12:56] <LocutusOfBorg> rbalint, already retried, looks it failed
[12:56] <LocutusOfBorg> in any case, looks a lp issue, right?
[12:56] <rbasak> Looks like an invalid "this is valid UTF-8" assumption
[12:57] <rbasak> Then again, is something dumping non-UTF8 to the terminal? Unless the locale is configured that way, it probably shouldn't do that either.
[12:59] <rbalint> rbasak, lp should then convert the output
[13:18] <Laney> Buildd toolchain package versions: launchpad-buildd_191~460~ubuntu18.04.1
[13:18] <Laney> https://git.launchpad.net/launchpad-buildd/commit/?id=25d8b32caed56ba725c2b946b67f3b8622ece9d2
[13:18] <Laney> I think that commit is missing
[13:18] <Laney> cjwatson: ^- do s390x images need upgrading?
[13:19] <Laney> Looks like that fix is in 193
[13:19] <Laney> (do you want me to ask the help contact?)
[13:20]  * Laney does so
[13:22] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (groovy-proposed) [2:22.0.1-0ubuntu1]
[13:24] -queuebot:#ubuntu-release- Unapproved: rejected adduser [source] (groovy-proposed) [3.118ubuntu3]
[13:34] <Laney> #launchpad people are investigating
[13:38] -queuebot:#ubuntu-release- Unapproved: accepted rtl8812au [source] (focal-proposed) [<IP_ADDRESS>75.20140902+dfsg-0ubuntu13~20.04.1]
[13:41] <rbalint> Laney, thanks!
[13:44] <Laney> apw: I'm seeing
[13:44] <Laney> awk: cmd. line:3: warning: command line argument `/home/ubuntu-archive/proposed-migration/var/data-b2/hirsute-proposed/Hints/kernel-testing-hints' is a directory: skipped
[13:44] <Laney> in britney logs
[13:44] <Laney> feels like a you thing :>
[13:48] <xnox> doko:  https://bugs.launchpad.net/ubuntu/+source/opensbi/+bug/1906668 should be fairly straight forward
[13:49] <doko> cpaelzer: ^^^
[13:52] <LocutusOfBorg> am I correct if I say that if we kick out graphviz 2.42.2-4build2 and restore 2.42.2-4build1 we can disentangle python and perl, and have python migrate?
[13:57] <xnox> doko:  https://bugs.launchpad.net/ubuntu/+source/usrmerge/+bug/1906671 for usrmerge
[13:58] <xnox> doko:  pinged sponsoree about adduser
[14:04] <LocutusOfBorg> can any ubuntu-archive please force-test-reset makedumpfile/1:1.6.8-1ubuntu1 ? it is already hinted, but the version increased
[14:05] <seb128> LocutusOfBorg, ubuntu-release you want, archive doesn't have access to hints
[14:05] <LocutusOfBorg> oops :/ sorry
[14:05] <LocutusOfBorg> maybe Laney can help here? :)
[14:06] <LocutusOfBorg> well, since I pinged ubuntu-archive, can anybody please have a look at graphviz to disentangle perl and python3-defaults?
[14:11] <doko> it is entangled, at multiple points, and I'm supposed to be afk
[14:14] -queuebot:#ubuntu-release- Unapproved: wireless-regdb (focal-proposed/main) [2018.05.09-0ubuntu1 => 2020.11.20-0ubuntu1~20.04.1] (core) (sync)
[14:14] -queuebot:#ubuntu-release- Unapproved: wireless-regdb (groovy-proposed/main) [2018.05.09-0ubuntu1 => 2020.11.20-0ubuntu1~20.10.1] (core) (sync)
[14:15] <Laney> LocutusOfBorg: can you do a merge proposal with the rationale? i'm just going to have lunch, you might make it easy enough for someone else to do
[14:15] <Laney> and indeed nack re: graphviz, that's not the only place
[14:15] <Laney> I think they're getting ready to be ready anyway
[14:15] -queuebot:#ubuntu-release- Unapproved: wireless-regdb (bionic-proposed/main) [2018.05.09-0ubuntu1~18.04.1 => 2020.11.20-0ubuntu1~18.04.1] (core) (sync)
[14:16] -queuebot:#ubuntu-release- Unapproved: wireless-regdb (xenial-proposed/main) [2018.05.09-0ubuntu1~16.04.1 => 2020.11.20-0ubuntu1~16.04.2] (core) (sync)
[14:17] <LocutusOfBorg> ack I still find difficult to parse the new update excuses (even if it is superior to the old one)
[14:20] -queuebot:#ubuntu-release- Unapproved: accepted wireless-regdb [sync] (groovy-proposed) [2020.11.20-0ubuntu1~20.10.1]
[14:21] -queuebot:#ubuntu-release- Unapproved: accepted wireless-regdb [sync] (focal-proposed) [2020.11.20-0ubuntu1~20.04.1]
[14:22] -queuebot:#ubuntu-release- Unapproved: accepted wireless-regdb [sync] (bionic-proposed) [2020.11.20-0ubuntu1~18.04.1]
[14:22] -queuebot:#ubuntu-release- Unapproved: accepted wireless-regdb [sync] (xenial-proposed) [2020.11.20-0ubuntu1~16.04.2]
[14:23] <apw> ^ these are all copies with binaries as they are destined for -security; pre-reviewed in the security compatible PPA
[14:36] -queuebot:#ubuntu-release- Unapproved: libevdev (groovy-proposed/main) [1.9.1+dfsg-1 => 1.9.1+dfsg-1ubuntu0.1] (core, i386-whitelist)
[14:38] <LocutusOfBorg> Laney, https://git.launchpad.net/~costamagnagianfranco/+git/hints-ubuntu/commit/?id=b081ba4bd635ef03867a9538ad2395d7e1f1cab1
[14:39] -queuebot:#ubuntu-release- Unapproved: libevdev (focal-proposed/main) [1.9.0+dfsg-1 => 1.9.0+dfsg-1ubuntu0.1] (desktop-core, i386-whitelist)
[14:40] <LocutusOfBorg> https://code.launchpad.net/~costamagnagianfranco/britney/+git/hints-ubuntu/+merge/394819
[14:40] <LocutusOfBorg> here we are ^^
[15:08] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.4 [amd64] (bionic-proposed) [5.4.0-1031.33~18.04.1]
[15:20] <rbalint> Laney, could you please remove libcbor-xs-perl from -proposed to not hold back perl? the build did not get better yet
[15:20] <rbalint> maybe sil2100 ^?
[15:27] -queuebot:#ubuntu-release- Unapproved: libevdev (bionic-proposed/main) [1.5.8+dfsg-1 => 1.5.8+dfsg-1ubuntu0.1] (desktop-core)
[15:28] <sil2100> rbalint: just the one from proposed, right?
[15:28] <rbalint> sil2100, yes, i think that will be enough
[15:28] <rbalint> sil2100, thanks!
[15:29] <sil2100> Ah, FTBFS on s390x right now
[15:29] <sil2100> Ok
[15:33] <sil2100> rbalint: done o/
[15:36] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.8 [s390x] (focal-proposed/main) [5.8.0-32.34~20.04.1] (no packageset)
[15:37] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.8 [ppc64el] (focal-proposed/main) [5.8.0-32.34~20.04.1] (no packageset)
[15:37] <rbalint> plusone i've triggered all qtwebengine-opensource-src  tests for arm64 to speed up queueing them, it holds back re2
[15:37] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.8 [arm64] (focal-proposed/main) [5.8.0-32.34~20.04.1] (no packageset)
[15:38] -queuebot:#ubuntu-release- Unapproved: libinput (groovy-proposed/main) [1.16.2-1 => 1.16.2-1ubuntu0.1] (desktop-core, i386-whitelist)
[15:38] <rbalint> plusone clickhouse still needs to be resolved, looking
[15:39] -queuebot:#ubuntu-release- Unapproved: libinput (focal-proposed/main) [1.15.5-1ubuntu0.1 => 1.15.5-1ubuntu0.2] (desktop-core, i386-whitelist)
[15:40] -queuebot:#ubuntu-release- Unapproved: libinput (bionic-proposed/main) [1.10.4-1ubuntu<IP_ADDRESS> => 1.10.4-1ubuntu<IP_ADDRESS>] (desktop-core)
[15:41] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.8 [amd64] (focal-proposed/main) [5.8.0-32.34~20.04.1] (no packageset)
[15:45] -queuebot:#ubuntu-release- New binary: linux-signed-dell300x [amd64] (bionic-proposed/universe) [4.15.0-1008.12] (no packageset)
[15:48] <Laney> rbalint: what is this "speed up queueing" that you're talking about?
[15:52] <rbalint> Laney, i triggered the tests manually since the arm64 package is built but tests were not queued
[15:52] <rbalint> Laney, like vorlon yesterday
[15:53] <Laney> how do you work out the list of tests to queue?
[15:54] <Laney> this results in double submissions, so I would really prefer not to get into the habit of doing this
[15:54] <rbalint> Laney, SELECT DISTINCT package from result JOIN test ON id = test_id WHERE triggers LIKE '%qtwebengine-opensource-src%' AND release LIKE 'hirsute';
[15:54] <Laney> (for results that aren't back by the next run)
[15:55] <rbalint> Laney, well, i don't do that as a hobby, just to migrate the entangled big transitions :-)
[15:56] <rbalint> plusone testing the clickhouse fix locally, will upload if it is enough
[15:58] <Laney> I'm sure you don't, but I don't want people getting into weird habits that waste resources, like bouncing on rmadison and then triggering tests in order to get their stuff in "fast"
[16:01] -queuebot:#ubuntu-release- Unapproved: apport (groovy-proposed/main) [2.20.11-0ubuntu50.2 => 2.20.11-0ubuntu50.3] (core, i386-whitelist)
[16:02] <rbalint> Laney, the 'waste' is below 1.0 USD: SELECT package, round(avg(duration/60)) from result JOIN test ON id = test_id WHERE triggers LIKE '%qtwebengine-opensource-src%' AND release LIKE 'hirsute' and arch = 'arm64' GROUP BY package;
[16:08] <Laney> rbalint: Come on, please :(
[16:09] <rbalint> Laney, it just try to keep in mind what costs i should ignore
[16:14] <Laney> If it's really so slow that you feel the need to resort to hacks then we should schedule working on some speedups, like having proposed-migration use the results from the sqlite database instead of going to swift each time
[16:19] <Laney> Regarding libcbor-xs-perl, don't we need to restore 1.71-1build2?
[16:34] <LocutusOfBorg> yep we need that
[16:34] <LocutusOfBorg> vorlon, btw, if you have some seconds of free time... missing build on i386: libusrsctp-dev, libusrsctp-examples, libusrsctp1 (from <IP_ADDRESS>+20200422-1)
[16:38] <blackboxsw> rbasak:  I think update-notifier upload has now been queued for review into -proposed for X, B, F and G https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=update-notifier
[16:38] <rbasak> Thanks
[16:39] <blackboxsw> rbasak: X and B contain additional commits to fix pep8/pyflakes issues that were introduced in the previously rejected SRU
[16:39] <LocutusOfBorg> mmm Laney looks like copying libcbor-xs-perl nmight fail
[16:39] <LocutusOfBorg> ./copy-package --from=ubuntu --to=ubuntu --from-suite=hirsute-proposed --to-suite=hirsute-proposed --include-binaries libcbor-xs-perl --version 1.71-1build2 --force-same-destination
[16:40] <LocutusOfBorg> this commands wants to copy only s390x binaries... ?
[16:40] <Laney> try it, apparently that list of binaries can be wrong for reasons I don't understand
[16:40] <LocutusOfBorg> done :)
[16:40] <RikMills> vorlon: I am looking at kbibtex. at the moment waiting to see if the debian uploader really wants to build with optional QtWebengine without bothering to make the build dep architecture specific. plus pondering if the failing test is really useful, given that it never passes in debian, and when it fails in ubuntu it has not actually done a sane job of testing what it is intended to (that the apps GUI runs)
[16:40] <vorlon> removed clickhouse from release pocket, which is the last blocker for perl+python+re2 currently shown on update_excuses
[16:40] <LocutusOfBorg> yay looks like it worked
[16:41] <Laney> worked afaics
[16:41] <Laney> woot
[16:41] <vorlon> unfortunately, after the britney merge it seems update_excuses is much less reliable than update_output used to be in showing all the blockers
[16:41] <vorlon> RikMills: ok
[16:42] <Laney> help would be appreciated in getting it more reliable :-)
[16:42] <vorlon> LocutusOfBorg: should just need someone to do a binary copy of that same version back to hirsute-proposed to trigger the i386 build
[16:42] <Laney> even identifying classes of problems, ideally in the form of testcases, would be a good first step
[16:43] <LocutusOfBorg> vorlon, can I do that?
[16:43] <blackboxsw> rbasak: bugs related xenial and bionic are LP: #1906436, LP: #1901627, LP: #1822340, LP: #1842508 and LP: #1881632 F and G releases have a subset of those bugs
[16:44] <vorlon> LocutusOfBorg: I believe any uploader can
[16:47] <vorlon> Laney: honestly, I'd rather go back to the previous behavior where we could use update_output to trace these things, by having britney not block them for consideration when it detects that related packages are not migratable
[16:49] <vorlon> Laney: the latest issue I've seen was that openscap wasn't shown as entangling perl and python until today - even though it's been in the archive since the 19th of November.  So britney seems to truncate its search once it finds *a* blocker, which seriously impairs parallelization
[16:49] <vorlon> (parallelization of work by developers)
[17:01] <Laney> I think the way we decide to write "(not considered)" is a bit buggy but I didn't manage to comprehend the problem when I looked the other week
[17:03] <Laney> We could make the notest runs have the ImplicitDependencyPolicy be non blocking, I don't think I'd contend that one
[17:03] <Laney> Less sure about doing it universally
[17:05] <vorlon> that would be an improvement, at least
[17:06] <Laney> http://autopkgtest.ubuntu.com/packages/baconqrcode/hirsute/ppc64el
[17:06] <Laney> What on earth has happened there
[17:07] <vorlon> the runners really like their bacon
[17:07] <rbalint> Laney, this was not me :-)
[17:10] <Laney>  php-bacon-qr-code | 2.0.2-2 | hirsute/universe          | all
[17:10] <Laney>  php-bacon-qr-code | 2.0.3-1 | hirsute-proposed/universe | amd64
[17:10] <Laney> something to do with this I'd say
[17:11] <vorlon> wtf
[17:12] <vorlon> well, should probably just force the package through regardless
[17:15] <Laney> yeah, I added a skiptest
[17:18] <vorlon> ah ok - I just added a force-reset-test, since the binary is now only available on amd64 and I wasn't sure if we would see future attempts to test on the archs where it will shortly no longer exist
[17:18] <Laney> I was thinking it'll clear itself up once in the release pocket (hopefully)
[17:18] <Laney> heh
[17:19] <Laney> shortest lived hint ever - assumed that reset-test was someone's previous attempt to get this to migrate, sorry
[17:22] <vorlon> Laney: ah :)
[17:24] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (focal-proposed) [2.664.10]
[17:42] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.8 [amd64] (focal-proposed) [5.8.0-32.34~20.04.1]
[17:42] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.8 [ppc64el] (focal-proposed) [5.8.0-32.34~20.04.1]
[17:42] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.8 [arm64] (focal-proposed) [5.8.0-32.34~20.04.1]
[17:42] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.8 [s390x] (focal-proposed) [5.8.0-32.34~20.04.1]
[17:43] -queuebot:#ubuntu-release- New: accepted linux-signed-dell300x [amd64] (bionic-proposed) [4.15.0-1008.12]
[17:46] <LocutusOfBorg> vorlon, I don't think the copy worked
[17:46] <LocutusOfBorg> ./copy-package --from=ubuntu --to=ubuntu --from-suite=hirsute-proposed --to-suite=hirsute-proposed --include-binaries libusrsctp  --force-same-destination
[18:01] <kyrofa> How much RAM do the builder VMs have for the archive? I need to try and duplicate an error
[18:17] <LocutusOfBorg> kyrofa, does this help? https://launchpad.net/ubuntu/+source/procenv/0.50-1ubuntu3
[18:17] <LocutusOfBorg> hint: look inside each build log
[18:20] -queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.13 => 2.20.11-0ubuntu27.14] (core, i386-whitelist)
[18:25] <kyrofa> LocutusOfBorg, yeah handy, thanks!
[18:25] <LocutusOfBorg> you have to thank Colin, who give me that hint around 5 years ago :)
[18:26] <LocutusOfBorg> I'm just a dumb copy-paste man :)
[18:26] <kyrofa> Haha, you're in good company
[18:40]  * enyc meows
[19:23] <vorlon> LocutusOfBorg: didn't work> did you get an error?
[19:24] <LocutusOfBorg> no error
[19:24] <xnox> did it do what you wanted, or did it not?
[19:24] <vorlon> LocutusOfBorg: error email?
[19:24] <vorlon> (since copies are asynchronous)
[19:25] <vorlon> I've just tried as well with 'copy-package -b -e <IP_ADDRESS>+20201102-2 libusrsctp --force-same-destination -s hirsute-proposed --auto-approve -y', I don't see a build record so waiting to see if I get an email
[19:25] <LocutusOfBorg> nope, no error I guess
[19:25] <LocutusOfBorg> no email I mean
[19:25] <LocutusOfBorg> but lots of lp goes into spam
[19:27] <vorlon> hmm the copy probably worked, but somehow the package is not in the packageset despite showing in germinate output
[19:27] <vorlon> digging
[19:29] <vorlon> oh I was looking at the focal germinate output :/  ok we should just remove these binaries from the release pocket, I'll follow throug
[19:31] <doko> Laney: autopkgtest for libcalendar-simple-perl/1.23-1: amd64: Regression ♻ , arm64: Regression ♻ , armhf: Regression ♻ , i386: Ignored failure, ppc64el: Regression ♻ , s390x: Regression ♻
[19:31] <doko> triggerd by perl, however that didn't show up earlier, and there doesn't seem to be any cycle involved
[19:35] <rbalint> doko, passing locally, i already retried them, but indeed, those did not show up for some reason
[19:35] <LocutusOfBorg> doko, it was failing since the begin
[19:35] <LocutusOfBorg> then a new version succeded and it migrated
[19:35] <LocutusOfBorg> so they are now seen as failures?
[19:36] <rbalint> LocutusOfBorg, that could be the explanation
[19:36] <LocutusOfBorg> it migrated 2 hours ago, the libcalendar-simple-perl
[19:36] <LocutusOfBorg> well, 4 hours ago
[19:37] <LocutusOfBorg> with the latest autosyncs and migrations, we lost something again in transitions
[19:37] <LocutusOfBorg> e.g. borgbackup has been syncd, but it should be fast
[19:37] <Eickmeyer[m]> Ok, I need some help. teward and I just reuploaded agordejo, which just completely FTBFS. In my PPA, it build perfectly just 40 minutes prior.  However, the reupload was to set the python compatibility variable which should take care of the 3.9 issue.
[19:42] <LocutusOfBorg> this is another issue then :)
[19:42] <Eickmeyer[m]> Indeed. Upstream was notified, but has made zero action on it.
[19:43] <LocutusOfBorg> are you sure PYTHONCOMPATVERSIONVERSION is a valid keyword?
[19:44] <Eickmeyer[m]> LocutusOfBorg: According to the docs, yes. https://www.python.org/dev/peps/pep-0606/#python-3-8
[19:45] <Eickmeyer[m]> Unless they typo'd the living junk out of it.
[19:46] <LocutusOfBorg> googling for it failed
[19:47] <Eickmeyer[m]> LocutusOfBorg: Specifically: https://www.python.org/dev/peps/pep-0606/#command-line
[19:51] -queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.27 => 2.20.1-0ubuntu2.28] (core)
[19:52] -queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.20 => 2.20.9-0ubuntu7.21] (core)
[19:54] <vorlon> LocutusOfBorg: yes, the autopkgtest policy is not good at detecting the difference between progressions and regressions
[19:54] <vorlon> a fix would be to notice that the version of the succeeding autopkgtest is higher than the failing one and should be ignored
[19:54] <LocutusOfBorg> or automatic retry?
[19:55] <vorlon> or that
[19:55] <LocutusOfBorg> I prefer more green rather than more yellow/red :)
[19:55] <LocutusOfBorg> but yes, looks like a good fix
[19:55] <vorlon> I prefer faster migrations without regressing ;)
[19:56] <LocutusOfBorg> I did the same retry in node-mqtt just today, passed from red to green and triggering regressions everywhere
[19:57] <vorlon> LocutusOfBorg: did you retry mariadb-10.5 for perl only on ppc64el? there are failures also on armhf and s390x
[19:58] <LocutusOfBorg> vorlon, I didn't
[19:59] <vorlon> LocutusOfBorg: didn't which?  I do see a running mariadb-10.5/ppc64el test with your name on it
[19:59] <LocutusOfBorg> yes, but I tried also armhf and s390x
[20:00] <vorlon> oh ok
[20:00] <vorlon> I don't see them running or in the queue, did they fail fast? :/
[20:01] <LocutusOfBorg> maybe they just finished...
[20:01] <LocutusOfBorg> not sure it was around half an hour ago
[20:01] <vorlon> a successful test takes ~40m and the timestamp on the test didn't look old enough
[20:02] <vorlon> ... and ppc64el just disappeared after running < 10m so it looks like they're probably all failures and we'll have logs to look at soon
[20:03] <LocutusOfBorg> I think mariadb is having some sadness
[20:03] <LocutusOfBorg> migrating mariadb-common/1:10.3.27-1~exp1/amd64 to testing makes mariadb-client-core-10.5/1:10.5.8-3/amd64 uninstallable
[20:03] <LocutusOfBorg> meh, -dev packages not ship anymore
[20:09] <LocutusOfBorg> sure now that there is an higher mariadb-common in hirsute (from 10.5), the 10.3 can't migrate anymore
[20:09] <LocutusOfBorg> :/
[20:26] <LocutusOfBorg> I uploaded what I think can be a fix
[20:27] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (groovy-proposed/main) [5.8.0-1014.15] (core, kernel)
[20:28] -queuebot:#ubuntu-release- New binary: linux-signed-kvm [amd64] (groovy-proposed/main) [5.8.0-1012.13] (core)
[20:40] <LocutusOfBorg> I'm doing rebuilds so we can kick out 10.3
[20:40] <vorlon> LocutusOfBorg: I see you've dropped mariadb-common from mariadb-10.3; but there are several other binaries from mariadb-10.3 which are older in -proposed than the versions in release pocket... (mariadb-server, mariadb-client)
[20:41] <LocutusOfBorg> vorlon, I think we should just rebuild reverse deps and move to 10.5
[20:41] <vorlon> s/several/two/ :)
[20:41] <LocutusOfBorg> not only two...
[20:41] <LocutusOfBorg> https://launchpadlibrarian.net/509718099/upload_20361202_log.txt
[20:41] <vorlon> ah
[20:42] <LocutusOfBorg> reverse deps are  ~5 packages
[20:42] <LocutusOfBorg> lets rebuild and move forward
[20:42] <vorlon> rebuilds sound good, but how quickly will that help us get the mariadb-10.5 autopkgtest failures cleared
[20:42] <mwhudson> ubuntu-archive can someone let https://launchpad.net/ubuntu/+source/rustc/1.44.1+dfsg1+llvm-3ubuntu1 out of NEW pls
[20:43] <vorlon> would removing mariadb-10.3 from -proposed now help?
[20:43] <LocutusOfBorg> vorlon, it won't help
[20:43] <LocutusOfBorg> binaries are already in release
[20:43] <LocutusOfBorg> the ones from mariadb-10.5
[20:43] <vorlon> mwhudson: done
[20:43] <mwhudson> vorlon: thanks!
[20:43] <LocutusOfBorg> so, removing mariadb-10.3 is the best way to move forward
[20:43] <Laney> doesn't 10.5 have passes with the longer set of triggers anyway? won't the next run get those?
[20:44] <vorlon> Laney: the retries are failing before getting to the actual tests
[20:44] <Laney> in https://autopkgtest.ubuntu.com/packages/m/mariadb-10.5/hirsute/armhf
[20:44] -queuebot:#ubuntu-release- New: accepted rustc [amd64] (hirsute-proposed) [1.44.1+dfsg1+llvm-3ubuntu1]
[20:44] -queuebot:#ubuntu-release- New: accepted rustc [armhf] (hirsute-proposed) [1.44.1+dfsg1+llvm-3ubuntu1]
[20:44] -queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (hirsute-proposed) [1.44.1+dfsg1+llvm-3ubuntu1]
[20:44] -queuebot:#ubuntu-release- New: accepted rustc [arm64] (hirsute-proposed) [1.44.1+dfsg1+llvm-3ubuntu1]
[20:44] -queuebot:#ubuntu-release- New: accepted rustc [s390x] (hirsute-proposed) [1.44.1+dfsg1+llvm-3ubuntu1]
[20:44] -queuebot:#ubuntu-release- New: accepted rustc [i386] (hirsute-proposed) [1.44.1+dfsg1+llvm-3ubuntu1]
[20:44] <Laney> the second result there has a perl/5.32.
[20:44] <Laney> 0-5 trigger
[20:45] <vorlon> LocutusOfBorg: I don't see why the mariadb-10.5 binaries being in release would cause the mariadb-10.5 autopkgtest to fail
[20:46] <doko> Laney: well, now it has a valid test (even three or four), but the 	2020-11-18 failure was never shown
[20:46] <vorlon> doko: because failures that are not regressions are not being shown on update_excuses output anymore, to make the page more manageable
[20:47] <vorlon> so it was never shown, until a progression caused britney to start considering it a regression
[20:47] <Laney> Right, it became a 'regression' when it migrated
[20:47] <Laney> At that point we should have requested a new test
[20:47] <doko> huh? what migrated?
[20:47] <Laney> because the migration could then cause *that* package to regress
[20:48] <doko> neither perl nor libcalendar-simple-perl migrated
[20:48] <vorlon> it doesn't depend on migration though; britney will consider it a regression as soon as a newer version of the package under test, present in -proposed, has passed
[20:48] <doko> there *is no newer version*
[20:49] <LocutusOfBorg>  2.0.0-1	release (universe)	5 hours ago
[20:49] <LocutusOfBorg> doko, ^^
[20:51] <doko> yes, and it takes >=5h for britney to show :-(
[20:52] <vorlon> yes; but in any case the autopkgtest log history shows up sooner and you can see the failed test triggered by perl was an older version than the current version
[20:55] <doko> no, balint's explicit trigger is 18:58:46, update_excuses was started 18:23:17, so you can't see it
[20:56] <doko> and yes, I looked before retrying
[20:58] <doko> Eickmeyer[m]: please stop using 3.8 ... http://launchpadlibrarian.net/509709488/agordejo_0.1.1-0ubuntu2_0.1.1-0ubuntu3.diff.gz
[20:59] <vorlon> LocutusOfBorg: I've removed mariadb-10.3 from -proposed and will retry the autopkgtests after the publisher runs
[20:59] <LocutusOfBorg> ack vorlon
[20:59] <LocutusOfBorg> I finished rebuilds so hopefully you will be able to remove 10.3 from release too?
[21:00] <teward> LocutusOfBorg: Eickmeyer[m]: even with Proposed working, while this builds *fine* in a schroot build by sbuild for hirsute with the proper -X argument to Python, it seems that something in the version of nuitka being called upon in -proposed explodes hard.  Which suggests the underlying problem is actually not in the agordejo package at all but the nuitka compatibility with Py3.9, regressions, and compatibility strings not being parsed
[21:00] <teward> so at the moment -0ubuntu3 needs to be pulled from proposed
[21:00] <teward> doko: ^
[21:00] <doko> it's harmless there, it ftbfs
[21:00] <teward> until such time that upstream and nuitka that's being used under the hood is fixed
[21:00] <teward> doko: it'll stay FTBFS until nuitka fixes their crap
[21:01] <teward> ten bucks says the underlying build env isn't 3.9 compatible yet ;)
[21:02] <teward> or agordejo upstream is not parsing version strings right
[21:06] <teward> ... nope, FTBFS is in nuitka
[21:06] <teward> so it's a nuitka needs to support Python 3.9 issue (because they actually CHECK supported version strings)
[21:57] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (groovy-proposed) [5.8.0-1014.15]
[21:57] -queuebot:#ubuntu-release- New: accepted linux-signed-kvm [amd64] (groovy-proposed) [5.8.0-1012.13]
[22:05] <cjwatson> Eickmeyer[m]: It says just PYTHONCOMPATVERSION further up the PEP, so that seems like a typo.  However, if you look at the top, that's a rejected PEP, and there's no match for PYTHONCOMPAT in the actual Python 3.9 codebase.
[22:06] <Eickmeyer[m]> cjwatson: See teward 's explanation.
[22:06] <cjwatson> Yes, I saw that too, just wanted to close the loop.
[22:08] <teward> didn't notice that was a rejected PEP, my brain hurts xD  Regardless, nuitka needs to fix their stuff ;)
[22:08] <mwhudson> packages that require a source-changing upload for each new python version are the best
[22:08] <teward> mwhudson: well, this is going to require their underlying builder to be fixed heh.  nuitka is a python builder framework, and... well it's broke :P
[22:09] <bdmurray> vorlon: Could you fully phase bluez? The package has stopped phasing due to the apport change which started reporting bluetoothd crashes so all the "regressions" are just bluetoothd noise.
[22:11] -queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (groovy-proposed/multiverse) [6.1.16-dfsg-1ubuntu<IP_ADDRESS> => 6.1.16-dfsg-4ubuntu<IP_ADDRESS>] (no packageset)
[22:11]  * cjwatson wonders why this thing absolutely *requires* nuitka rather than being able to fall back to using the interpreter like everything else
[22:12] <LocutusOfBorg> please reject this virtualbox-hwe ^^
[22:14] <vorlon> bdmurray: which release?
[22:14] <vorlon> bdmurray: looks like groovy
[22:17] <vorlon> bdmurray: (done)
[22:20] <bdmurray> vorlon: yes groovy, thanks
[22:21] -queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (groovy-proposed) [6.1.16-dfsg-4ubuntu<IP_ADDRESS>]
[22:37] <Laney> proposed-migration did find that test result I mentioned in this run, fwiw
[22:38] <Laney> (perl -> mariadb-10.5/ppc64el)
[22:39] <Laney> at least afaics from my phone :>
[22:39] <mruffell> ubuntu-archive: I seem to have caused a regression in the recent adcli SRU for Bionic. Regression bug: https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1906627 SRU bug: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703, can I get some help removing the package from -security and stopping phasing to -updates
[22:39] <mruffell> I am investigating the failure now
[22:40] <mruffell> sssd is not affected, seems to be a problem with the default change to GSS-SPNEGO from GSS-API in adcli
[22:41] <LocutusOfBorg> thanks
[22:43] -queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (groovy-proposed/multiverse) [6.1.16-dfsg-1ubuntu<IP_ADDRESS> => 6.1.16-dfsg-4ubuntu<IP_ADDRESS>] (no packageset)
[22:45] -queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (focal-proposed/multiverse) [6.1.10-dfsg-1~ubuntu<IP_ADDRESS> => 6.1.16-dfsg-4ubuntu<IP_ADDRESS>] (no packageset)
[22:48] -queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.10-dfsg-1~ubuntu<IP_ADDRESS> => 6.1.16-dfsg-4~ubuntu<IP_ADDRESS>] (ubuntu-cloud)
[22:49] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1104.115] (kernel)
[22:49] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-127.130~16.04.1] (kernel)
[22:49] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1101.112~16.04.1] (kernel)
[22:50] -queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1101.112] (no packageset)
[22:50] -queuebot:#ubuntu-release- New binary: linux-signed-oem-5.10 [amd64] (focal-proposed/universe) [5.10.0-1006.7] (no packageset)
[22:50] -queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1075.80] (no packageset)
[22:50] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-127.130~16.04.1] (kernel)
[23:07] <vorlon> rolling back borgbackup, which has reset python3-defaults as a candidate >_<
[23:09] <vorlon> I am going to disable autosyncs for a bit, too many packages entangled to keep playing whack-a-mole especially with the current britney runtimes
[23:09] <LocutusOfBorg> the tests for borgbackup should be already finished
[23:09] <vorlon> LocutusOfBorg: yes and 3 of them failed
[23:10] <LocutusOfBorg> oh... :/
[23:10] <vorlon> so I'm not letting that crap block
[23:10] <LocutusOfBorg> flaky tests are flaky
[23:11] <LocutusOfBorg> I had to upload a new virtualbox-hwe because the groovy upload otherwise can't be versioned properly
[23:11] <LocutusOfBorg> if you are in a hurry with the transition please rollback it too
[23:12] <vorlon> I don't see virtualbox-hwe was previously in -proposed and tied to the transitions, so shouldn't reset things?
[23:23] -queuebot:#ubuntu-release- New binary: libavif [ppc64el] (hirsute-proposed/universe) [0.8.4-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- Unapproved: update-notifier (focal-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[23:28] -queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (focal-proposed) [<IP_ADDRESS>]
[23:28] -queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (focal-proposed) [<IP_ADDRESS>]
[23:31] -queuebot:#ubuntu-release- New binary: golang-pault-go-ykpiv [ppc64el] (hirsute-proposed/universe) [1.3.4-1] (no packageset)
[23:31] -queuebot:#ubuntu-release- New binary: libavif [s390x] (hirsute-proposed/universe) [0.8.4-1] (no packageset)
[23:31] -queuebot:#ubuntu-release- New binary: libavif [amd64] (hirsute-proposed/universe) [0.8.4-1] (no packageset)
[23:36] -queuebot:#ubuntu-release- New binary: golang-pault-go-ykpiv [amd64] (hirsute-proposed/universe) [1.3.4-1] (no packageset)
[23:36] -queuebot:#ubuntu-release- New binary: libavif [riscv64] (hirsute-proposed/universe) [0.8.4-1] (no packageset)
[23:37] -queuebot:#ubuntu-release- New binary: golang-pault-go-ykpiv [riscv64] (hirsute-proposed/universe) [1.3.4-1] (no packageset)
[23:41] -queuebot:#ubuntu-release- New binary: linux-signed-gkeop-5.4 [amd64] (bionic-proposed/main) [5.4.0-1006.7~18.04.1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: golang-pault-go-ykpiv [s390x] (hirsute-proposed/universe) [1.3.4-1] (no packageset)
[23:43] -queuebot:#ubuntu-release- New binary: linux-signed-gkeop [amd64] (focal-proposed/universe) [5.4.0-1006.7] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: libavif [arm64] (hirsute-proposed/universe) [0.8.4-1] (no packageset)
[23:44] -queuebot:#ubuntu-release- New binary: libavif [armhf] (hirsute-proposed/universe) [0.8.4-1] (no packageset)
[23:47] <mwhudson> anyone remember why we still build rustc and cargo on i386?
[23:48] <mwhudson> because uggh https://launchpad.net/~mwhudson/+archive/ubuntu/cargo-testing/+build/20361433
[23:48]  * mwhudson needs food before that makes any sense