[11:42] <bluesabre> Hello desktoppers!
[11:42] <bluesabre> I was looking at https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/desktop-minimal to figure out the snap-store... and saw snap:snapd-desktop-integration ... is this something Xubuntu should include?
[11:42] <bluesabre> And... do I need to do anything special to get the right version of snap-store? When I was doing some early testing, I had to install from edge to get the new version instead of the gnome-software fork.
[11:45] <seb128> bluesabre, you should include snapd-desktop-integration probably yes, it handles things like themes installation or update-available/refresh notifications
[11:47] <seb128> bluesabre, @snap-store, is that in context of iso building? we could't publish the new codebase to stable easily since it would auto-upgrade systems on the old codebase and we were not at feature parity, unsure what's the status now though
[11:47] <seb128> but if you build an iso livecd-rootfs will default to use the stable/ubuntu-xx.yy channel and we have the new flutter codebase published there so you will get the right one
[11:50] <bluesabre> seb128: Perfect, that's what I needed to know. Thank you!
[11:51] <seb128> yw!
[13:43] <seb128> ricotz, hey, I got an email through the 'contact admin' from mozillateam on launchpad to point out that the firefox ppa build were failing on arm ... is that a known issue/something we care about?
[13:52] <ricotz> seb128, hey, unfortunately this is true for xenial/bionic/focal builds, was there a specific series mentioned?
[13:53] <seb128> ricotz, bionic and focal
[13:53] <ricotz> jammy and later have llvm15 which results in successful builds
[13:54] <seb128> from a quick look to one log it seemed like a python thing but maybe I read an unrelevant part of the log
[13:54] <ricotz>  4:02.76 clang: error: the clang compiler does not support '-march=armv8.2-a+dotprod+i8mm'
[13:54] <seb128> I wouldn't bother about xenial/bionic since they are series out of support at the Ubuntu level
[13:54] <seb128> ah
[13:55] <seb128> anyway I don't think that's something we should invest efforts on, I just wanted to check the status to reply to the user
[13:55] <ricotz> that is for focal, bionic has more problems
[13:56] <ricotz> I was hoping _bandali would have a moment to look into the focal failure
[13:56] <ricotz> https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+sourcepub/15698561/+listing-archive-extra
[13:57] <ricotz> so fixing this is reasonable ^
[13:57] <seb128> bandali, ^ could you add that to your backlog, that's going to be an issue for the incoming release right?
[13:58] <ricotz> seb128, already an issue with 121
[13:58] <ricotz> https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+packages?field.name_filter=&field.status_filter=&field.series_filter=focal
[13:58] <seb128> ah, we released without arm, I hadn't noticed
[13:58] <ricotz> yeah :(
[17:09] <bandali> ricotz, seb128, i did look, but unfortunately couldn't think of or find any workarounds
[17:09] <bandali> for arm64, i'm afraid our clang version is simply too old (we had to bump it down to workaround failures all across)
[17:10] <bandali> for armhf, i saw a workaround by the Debian maintainer and thought of applying it on our side as well, but iirc the workaround was already merged in for the then-upcoming upstream stable release and didn't seem to help us on ubuntu/focal
[17:11] <bandali> the only/main reasonable way forward out of the mess is getting newer llvm/clang backported, which i've just requested to the foundations team, but i'm not sure if/when they will do that
[17:11] <bandali> (at least as far as i can see)
[18:31] <ricotz> bandali, llvm-13 works for focal, but it is stuck in proposed and probably abandoned - https://launchpad.net/ubuntu/+source/llvm-toolchain-13 - https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+sourcepub/15699941/+listing-archive-extra
[18:33] <ricotz> it looks like an existing solution


[21:17] <mup> PR operator#496 opened: Make add_layer()'s "combine" a keyword-only parameter <Created by benhoyt> <https://github.com/canonical/operator/pull/496>
[23:08] <mup> PR operator#497 opened: Update service config's "environment" to plain dict <Created by benhoyt> <https://github.com/canonical/operator/pull/497>


[17:28] <Mathisen> any alterantive to portainer need something to manage multiple docker containers remote with webgui


[03:29] <engineer-pearl> Hi. I'm trying to start a crontab job but it doesn't seem to be starting. I don't seem to have the log files either...
[03:31] <engineer-pearl> Update: I have found some logs in the syslog but am not sure that there is anything useful in there
[03:31] <tsimonq2> engineer-pearl: Can you please paste the output of your crobtab?
[03:33] <engineer-pearl> The only output of crontab -l that is not commented is "@reboot (. ~/.profile; /user/bin/screen -dmS gameserver-screen /home/engineerpearl0/bootscript.sh)"
[03:33] <sarnold> put a full path to the .profile
[03:33] <sarnold> also i'm not sure if the () bit actually works, I've never seen that, never tried that :)
[03:33] <tsimonq2> ^
[03:34] <engineer-pearl> running the reboot now
[03:35] <engineer-pearl> still no screen to be resumed
[03:36] <sarnold> heh
[03:36] <sarnold> /user/bin/screen
[03:36] <sarnold> took me three tries to spot it
[03:37] <tsimonq2> O__o
[03:37] <engineer-pearl> Yep that would do it
[03:40] <engineer-pearl> The command is now "@reboot /usr/bin/screen -dmS gameserver-screen /home/engineerpearl0/bootscript.sh" and it still is saying there is no screen to be resumed
[03:41] <engineer-pearl> OH
[03:41] <engineer-pearl> I forgot the ./
[03:42] <tsimonq2> engineer-pearl: Got it now? :D
[03:43] <engineer-pearl> I hopefully will when I remember if the ./ goes in the beginning (before the /home) or right before the name of the file
[03:44] <sarnold> note that the shell command for 'source' is '.'
[03:44] <sarnold> the / is part of the path
[03:47] <engineer-pearl> ... still no screen to be resumed...
[03:48] <engineer-pearl> isn't there supposed to be a crontab error log somewhere?
[03:48] <sarnold> what's the line now? is there anything in the /var/log/auth.log? or syslog?
[03:48] <sarnold> annoyingly, cron likes to _email_ errors :/ that made more sense in the 80s and 90s..
[03:49] <engineer-pearl> @reboot /usr/bin/screen -dmS gameserver-screen /home/engineerpearl0/./bootscript.sh
[03:49] <engineer-pearl> I don't have an email server on this machine so its emailing is doing no good
[03:50] <engineer-pearl> authlog has a lot of sessions opening and closing
[03:50] <engineer-pearl> syslog is mentioning hourly stuff but nothing relevant
[03:52] <engineer-pearl> is there somewhere the emails sit if they can not be actually emailed?
[03:52] <sarnold> it's possible that your bootscript.sh is expecting a different PATH too. read through it, see what executables it calls without using full paths?
[03:54] <engineer-pearl> Not calling any exicutables without full paths, but I changed it from bash .......... to just /path/./file
[03:54] <sarnold> ?
[03:54] <engineer-pearl> When running a bash script I usually do bash filename
[03:55] <sarnold> sure, that's handy if the sysadmin puts 'noexec' on your homedir filesystem
[03:55] <engineer-pearl> nope, didn't fix it.
[03:56] <engineer-pearl> It shouldn't have even had time to get past "/home/engineerpearl0/gitasist/./gitupdate pull" [[a script I wrote]]
[03:56] <sarnold> btw all the /./ things in your paths aren't needed
[03:57] <sarnold> . in a path refers to 'this directory'; if you're execugin things not in PATH, say, ./scripts/foo   then the . says 'start from the current working directory'
[03:57] <engineer-pearl> it is asking for a password... I thought screen would protect me from that but...
[03:57] <engineer-pearl> I thought the ./ helped to exicute things
[03:58] <sarnold> it can if the file you're executing is in the current working directory but not in the PATH with a fully-qualified directory name
[03:59] <engineer-pearl> hmm... hold on I need to figure out an escape and move my command to my root folder ((long story short: oops"
[04:00] <engineer-pearl> Would screen close imediatly if it were running as a dameon and it ran into a request for password?
[04:01] <sarnold> I would hope not, but it can't really tell what's a request for password or not, it's all just IO to screen
[04:02] <engineer-pearl> well I adjusted that so it doesn't happen again
[04:03] <engineer-pearl> still no screen
[04:03] <engineer-pearl> I don't understand rrrrrgh some error logs would be helpful here!!!!
[04:04] <sarnold> you can try looking in /var/spool/mail/
[04:07] <engineer-pearl> I found something odd but irrelevant.
[04:08] <engineer-pearl> :/
[04:18] <engineer-pearl> here's something: there's something about a crontab.allow list
[04:18] <engineer-pearl> which of course I misspelled
[04:20] <sarnold> ay, if you've fiddled with the /etc/cron.allow or /etc/cron.deny files then you've got to make sure they still describe what you want; but I think the default is anyone is allowed to use cron, no?
[04:20] <engineer-pearl> not according to the man page
[04:21] <engineer-pearl> "If neither of these files exists, then depending on site-dependent configuration parameters,  only  the  super user will be allowed to use this command, or all users will be able to use this command."
[04:21] <engineer-pearl> so it's hit or miss
[04:22] <engineer-pearl> wait, is @reboot allowed for basic users?
[04:22] <sarnold> sure, from vixie's point of view; I think our configuration allows anyone to use  it though; I don't have any /etc/cron.{allow,deny} files, but my crontab seems to work okay...
[04:22] <engineer-pearl> YEP THAT'S THE PROBLEM RIGHT THERE
[04:28] <engineer-pearl> or not
[05:09] <engineer-pearl> I have an update towards the good! I have error logs now!
[05:15] <sarnold> engineer-pearl: great! :) that is a worthy accomplishments :)
[05:15] <engineer-pearl> still working on finding a replacement for runuser though. aparently that's not allowed. -_o_-
[05:17] <engineer-pearl> oooh found one
[05:17] <engineer-pearl> giving it a test
[05:18] <sarnold> uh
[05:18] <sarnold> why not just use the specified user's crontab?
[05:18] <engineer-pearl> because that won't run at reboot
[05:18] <engineer-pearl> :/
[05:18] <sarnold> o_O
[05:18] <engineer-pearl> That was my first setup
[05:19] <sarnold> normally cron's @reboot thing is used because users can't write their own sysv-init scripts or upstart configurations or systemd unit files
[05:20] <engineer-pearl> You're talking over my head but I'm listening
[05:21] <engineer-pearl> I need to run a bash script at startup, and if there is a way to do it that won't rely on crontab I'm in
[05:21] <engineer-pearl> ((I have never gotten that thing to work))
[05:21] <sarnold> what release are you on?
[05:22] <engineer-pearl> Ubuntu 16.04.1 LTS
[05:22] <engineer-pearl> (I just upgraded today
[05:34] <sarnold> engineer-pearl: okay, it's a little complicated to write systemd unit files but then you can manage it with the systemd tools -- systemctl could then enable or disable it, you can have it depend upon e.g. networking to be up and running, and so on
[05:34] <sarnold> the plus side to systemd is the docs are pretty good: https://www.freedesktop.org/software/systemd/man/systemd.unit.html and https://www.freedesktop.org/software/systemd/man/systemd.service.html# should be your starting points
[05:34] <engineer-pearl> oh uh... is this easier to learn or more flexible than than upstart? I can stop working on that if it is easier.
[05:35] <sarnold> I think systemd is more flexible than upstart; I think upstart is easier than systemd
[05:35] <sarnold> but 16.04 LTS uses systemd as init and service manager, so that's what's there :) hehe
[05:36] <engineer-pearl> Okay then I'll switch over
[05:36] <sarnold> there are a lot of examples in /lib/systemd/system/ that you can copy from too :)
[05:37] <engineer-pearl> Umm... question: I'm trying to run it in "screen" so I can access it later. Do I need to make any adjustments later?
[05:37] <engineer-pearl> ((one of the things I am doing is starting up a game which has terminal access. I want the game to start up, but I also want that access))
[05:37] <sarnold> ahhh so screen wasn't just for getting it to run persistently? hrm...
[05:37] <engineer-pearl> oh is that going to make it weirder
[05:38] <sarnold> I haven't seen screen used in a systemd unit file before. I can't think of anything off-hand that would keep it from working...
[05:41] <engineer-pearl> Lots of fancy files... doesn't look to be in bash but idk if I'd know them at this level...
[05:41] <sarnold> engineer-pearl: well, here's a dude who starts screen to start rtorrent: http://www.linuxveda.com/2014/04/28/autostart-process-gnu-screen-systemd/
[05:41] <sarnold> indeed it's very much not bash. that's good and bad.
[05:41] <engineer-pearl> :/ so much for just getting a script to run at startup I guess
[05:41] <sarnold> and this guy's got some insane cool tmux thing. Dunno -why- but he's got one: http://askubuntu.com/a/802272/33812
[05:42] <engineer-pearl> wait this line looks like what I want! Ubuntu 16.04.1 LTS
[05:42] <engineer-pearl> hold on didn't copy
[05:42] <engineer-pearl> ExecStart=/usr/bin/screen -d -m -S rtorrent /usr/bin/rtorrent
[05:42] <sarnold> I thought you'd like that bit :)
[05:44] <engineer-pearl> I have questions but it is late on a night where I have to be up bright and early
[05:44] <engineer-pearl> :/
[05:44] <sarnold> ugh :(
[05:44] <engineer-pearl> oh poop poop poop
[05:45] <engineer-pearl> IIf I do it this way, I don't know how to make it so I can attach
[05:45] <engineer-pearl> It will be owned by not-me
[05:45] <sarnold> it'd be owned by whatever user you configure here
[05:45] <engineer-pearl> If it is owned by me, I should be able to attach, right?
[05:46] <sarnold> so you could do something like 'sudo -u USERNAME screen -RAD'
[05:51] <engineer-pearl> I'm not entirely sure about the command but yeah, that seems about right, expecially the r
[05:52] <sarnold> hehe
[05:52] <sarnold> screen -RAD was just the thing I memorized because screen's baffling array of command line options is baffling
[05:52] <engineer-pearl> okay, so I've got the tabs, and I'll look into it later
[05:52] <sarnold> (I switched to tmux ages ago for no real good reason)
[05:53] <sarnold> there I think it's just 'tmux attach' :) heh
[05:53] <engineer-pearl> but for now I bid thee a good night
[05:53] <sarnold> you also, have fun :)
[08:25] <lordievader> Good morning
[11:10] <SipriusPT> Hello guys
[11:11] <SipriusPT> I have a smart host (remote.domainX.pt) connected with a remote mail server (mail.domainY.pt), that uses getmail to receive mail from that mail.domainY.pt, and then reroute it with sendmail to local user accounts in this server. My smart host uses mydomain as domainX.pt, config in postfix.
[11:11] <SipriusPT> I am able to login clients with this smart host, using domainX.pt. To send mail i am using smtp_sasl_password_maps:
[11:11] <SipriusPT><EMAIL_ADDRESS>test@domainX.pt:qwe12
[11:11] <SipriusPT> With getmail i was using as destination:
[11:11] <SipriusPT> [destination] type = MDA_external path = /usr/sbin/sendmail arguments = ("-bm", "test") unixfrom = true
[11:12] <SipriusPT> And didnt notice that i was using my @remote.domainX.pt local domain instead of the @domainX.pt do receive mail at postfix.
[11:12] <SipriusPT> When i tried to redirect mail (with postfix aliases) from a gmail account through this smart host to another gmail account, postfix didnt send my mails with @domainX.pt, it sends as @remote.domainX.pt, and as expected i receive a message from my remote server saying:
[11:12] <SipriusPT> Dec  6 14:37:12 remote.domainX.pt postfix/smtp[28504]: 0B8BD259F57<EMAIL_ADDRESS><EMAIL_ADDRESS>relay=mail.domainX.pt[]:25, delay=0.1, delays=0/0.01/0.07/0.02, dsn=5.0.0, status=bounced (host mail.domainX.pt[] said: 550-Verification failed for<EMAIL_ADDRESS>550-No Such User Here 550 Sender verify failed (in reply to RCPT TO command))
[11:12] <SipriusPT> After some tests at sendmail through getmail, i also notice that i could only use local user account names as destination or use full email name only with @remote.domainX.pt and not @domainX.pt as i was expecting.
[11:12] <SipriusPT> I have also tested with virtual_alias_maps instead of aliases from alias_maps but with that there is no domain associated to my local accounts, it can only be used to local delivery.
[11:12] <SipriusPT> So i am trying to figure out how can i solve this with postfix, to handle just @domainX.pt to receive mail instead of @remote.domainX.pt but i am not seeing a way to fix this.
[11:13] <SipriusPT> Here is my main.cf: http://pastebin.com/d9hZaTwp
[13:43] <jonah> Hi can anyone please help me out with server downtime. I seem to be getting attacked but hoped someone could help with where. Netstat isn't showing a lot of connections but it seems like a dos as my server is going offline frequently. thanks for any help
[13:44] <mybalzitch> jonah: whats your isp say
[13:45] <jonah> mybalzitch: they are useless and not answering the phone
[13:46] <mybalzitch> do your mrtg/cacti/whatever port graphs indicate you are being dos'd?
[13:57] <zul> coreycb:im going to drop the arm patch we were carrying for nova its no longer needed apparently
[13:58] <coreycb> zul, ok if you are sure
[13:59] <zul> coreycb: i asked
[13:59] <coreycb> zul, cool
[14:27] <zul> coreycb: http://pastebin.ubuntu.com/23603616/
[14:33] <showaz> Greeting, what is best to use a RAID controller support ubuntu? video streaming storage="40TB" & SSD
[14:34] <coreycb> zul, maybe transport_url is missing from nova.conf?
[14:36] <zul> coreycb: yep
[14:37] <zul> coreycb: ill figure it out
[15:30] <zul> coreycb: think i have a fix...testing it
[16:12] <zul> coreycb: nova should be fine again
[16:30] <protn> hi
[16:30] <protn> who here uses evolution?
[16:30] <protn> it acting weird with some accounts
[16:30] <protn> wont read imap folder
[16:30] <protn> yet
[16:35] <protn> hehehehe
[17:15] <Pinkamena_D> using ldapsearch I am trying to get info about one user, but the result comes back with a search reference. How do I tell it to follow the reference?
[17:27] <tarpman> Pinkamena_D: I don't believe ldapsearch has built-in support for chasing references
[17:36] <SipriusPT> hello guys
[17:37] <SipriusPT> http://serverfault.com/questions/819844/not-able-to-forward-mail-from-external-domains-through-relays
[17:37] <SipriusPT> anyone?
[19:30] <solidpizza> hello, I am wondering what is the simplest way to set up a git server with public clones and authenticated push. I have done this before with ssh and git-daemon but it was a struggle and I can't figure it out again.
[19:30] <solidpizza> and is there a guide that works for this?
[19:33] <tarpman> solidpizza: I had good luck with gitolite3 - it provides a github'ish ssh interface i.e. git@git.example.com:owner/repo - and apache for the r/o http access
[19:45] <Pici> solidpizza: I like gitlab, but its definitely a heavier solution.
[20:56] <engineer-pearl> I am trying to make a script run at startup, and am currently using http://www.linuxveda.com/2014/04/28/autostart-process-gnu-screen-systemd/ as a template, but my thing is not running. Is there something that breaks down the parts for me so I can figure out what is going wrong?
[21:03] <engineer-pearl> Status upstart gives the error ""com.ubuntu.Upstart" does not exist"
[21:05] <tarpman> engineer-pearl: you said you're using ubuntu 16.04? upstart is gone, replaced by systemd
[21:06] <engineer-pearl> oops I meant status systemd
[21:06] <tarpman> 'status' is a command that interacts with upstart
[21:06] <engineer-pearl> huh, odd. I've used it for a few other things. Must be because I upgraded, so it's not a new install.
[21:07] <engineer-pearl> So what's systemd's method of checking things?
[21:08] <tarpman> service xx status
[21:08] <engineer-pearl> oh backwards got it
[21:08] <tarpman> 'service' is a generic tool that will handle all kinds of services (init scripts / upstart / systemd) properly
[21:10] <engineer-pearl> well it looks like I can't have it check its own service... hmm
[21:10] <tarpman> what are you trying to do, exactly?
[21:10] <engineer-pearl> run a script that opens screen and does some stuff at startup. So far I have yet to confirm that it actually opens screen
[21:11] <tarpman> I meant which service are you trying to check the status of
[21:12] <engineer-pearl> I'm trying to get my script (currently named<EMAIL_ADDRESS>running, and I wanted to know if systemd was having issues so I could move forward
[21:12] <engineer-pearl> Looks like it's not found.
[21:16] <engineer-pearl> I was following the instructions here: http://www.linuxveda.com/2014/04/28/autostart-process-gnu-screen-systemd/
[21:16] <engineer-pearl> Are there better ones somewhere?
[22:10] <rebootd> Running 16.04 server for an media server, with no-ip for dynamic dns. I can ssh in via the WAN DNS name & ip, but not from a LAN ip. ufw is disabled. openssh is listening on all ip's. what am I missing?
[22:43] <rebootd> fyi, it was an ethernet adapter conflict. server was confused about which interface should respond.


[16:00] <slyon> o/
[16:00] <ogayot> \o
[16:00] <bdrung> \o
[16:00] <dbungert> o/
[16:00] <ginggs> o/
[16:00] <xypron> o/
[16:01] <jawn-smith> #startmeeting Weekly Ubuntu Foundations team
[16:01] <meetingology> Meeting started at 16:01:31 UTC.  The chair is jawn-smith.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[16:01] <meetingology> Available commands: action, commands, idea, info, link, nick
[16:01] <jawn-smith> The weekly status is here:
[16:02] <jawn-smith> #link https://discourse.ubuntu.com/t/foundations-team-updates-thursday-17-november-2022/32286/
[16:02] <jawn-smith> Let's all take our usual time to read and ask questions
[16:02] <jawn-smith> and congratulate waveform on upload rights
[16:02] <dbungert> :tada:
[16:02] <waveform> (or, react with horror ;)
[16:02] <mclemenceau> o/
[16:03] <samirkamerkar> :clap:
[16:04]  * juliank did not make status update writing yet
[16:06] <jawn-smith> #topic Release incoming bugs
[16:06] <jawn-smith> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-kk-incoming-bug-tasks.html#foundations-bugs
[16:06] <jawn-smith> Just one
[16:07] <jawn-smith> I believe we discussed and determined this one was with the desktop team
[16:07] <jawn-smith> Is that correct?
[16:07] <bdrung> yes
[16:08] <jawn-smith> Okay then, moving on
[16:08] <jawn-smith> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs
[16:08] <jawn-smith> Two here
[16:08] <jawn-smith> bug 1965094
[16:08] -ubottu:#ubuntu-meeting- Bug 1965094 in ubuntu-drivers-common (Ubuntu) "'Additional Drivers' application crashes on startup" [High, Confirmed] https://launchpad.net/bugs/1965094
[16:08] <jawn-smith> I believe this was also with desktop, is that correct?
[16:09] <vorlon> kernel really
[16:09] <vorlon> it's already assigned, nothing for us
[16:09] <jawn-smith> Thanks, moving on
[16:09] <jawn-smith> bug 1993037
[16:09] -ubottu:#ubuntu-meeting- Bug 1993037 in debianutils (Ubuntu) "Ubuntu 22.04, debianutils moved run-parts into /usr/bin, breaking systemd-cron in the course" [Undecided, Incomplete] https://launchpad.net/bugs/1993037
[16:09] <jawn-smith> Has some more information this time
[16:10] <slyon> the reporter says he doesn't have usrmerge installed, which would explain the failure
[16:10] <vorlon>  I'll follow up on the bug
[16:10] <slyon> thx
[16:10] <jawn-smith> indeed, thanks vorlon
[16:11] <vorlon> having a not-usrmerged system is not supported on jammy
[16:11] <jawn-smith> bdrung: you had a bug that didn't make it into the report, right?
[16:12] <bdrung> https://bugs.launchpad.net/ubuntu/+source/python-tz/+bug/207604 (tagged rls-ll-incoming)
[16:12] -ubottu:#ubuntu-meeting- Launchpad bug 207604 in python-tz (Ubuntu) "pytz includes a hard coded list of time zone names" [Medium, Confirmed]
[16:13] <bdrung> python-tz needs to be updated in SRUs every time a timezones are added or renamed and tzdata is updated several times a year
[16:13] <vorlon> I don't think it needs to be updated *every* time
[16:13] <vorlon> only when there are changes to tz names?
[16:15] <jawn-smith> Who wants to SRU this to all the way back to bionic
[16:15] <jawn-smith> ?
[16:16] <jawn-smith> Ah apparently the SRU has been done, we are just discussing a way to solve this problem better in the future
[16:18] <bdrung> yes, this ticket is about the long term solution.
[16:19] <jawn-smith> Okay let's discuss the foundations-todo list
[16:19] <jawn-smith> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/foundations-todo-bug-tasks.html
[16:20] <jawn-smith> That's a hefty list
[16:20] <jawn-smith> I'm going to sort by importance and then only look at ones with no assignee
[16:20] <jawn-smith> bug 1929860
[16:20] -ubottu:#ubuntu-meeting- Bug 1929860 in grub2 (Ubuntu Bionic) "initrdfail can result in resuming with different initrd images and hanging resume" [Undecided, In Progress] https://launchpad.net/bugs/1929860
[16:21] <jawn-smith> This has no assignee but is Fix Released
[16:22] <juliank> let's untag that for now, if it comes back we can still do it
[16:22] <jawn-smith> Okay sounds good
[16:23] <jawn-smith> bug 1992649
[16:23] -ubottu:#ubuntu-meeting- Bug 1992649 in subiquity (Ubuntu) "cannot find current revision for snap subiquity" [Critical, Incomplete] https://launchpad.net/bugs/1992649
[16:23] <jawn-smith> xypron: this may be fixed, can you look into that?
[16:25] <jawn-smith> Thanks for verifying the fix
[16:25] <jawn-smith> bug 1981109
[16:25] -ubottu:#ubuntu-meeting- Bug 1981109 in livecd-rootfs (Ubuntu Jammy) "server image pulls in ModemManager via fwupd, consumes 25MiB RAM in every container" [High, Triaged] https://launchpad.net/bugs/1981109
[16:26] <vorlon> that's mine to follow through on
[16:26] <jawn-smith> Thanks vorlon
[16:26] <vorlon> I'll jfdi it this week so it doesn't drag into the new year
[16:26] <jawn-smith> bug 1982511
[16:26] -ubottu:#ubuntu-meeting- Bug 1982511 in grub2-unsigned (Ubuntu Focal) "Intermittent 'Synchronous Exception' on arm64" [High, Triaged] https://launchpad.net/bugs/1982511
[16:28] <jawn-smith> This is with juliank
[16:28] <jawn-smith> bug 1983522
[16:28] -ubottu:#ubuntu-meeting- Bug 1983522 in cryptsetup (Ubuntu) "cryptroot-* autopkgtests fail on Ubuntu" [High, Confirmed] https://launchpad.net/bugs/1983522
[16:30] <jawn-smith> waveform to look at this
[16:30] <jawn-smith> Thanks!
[16:31] <jawn-smith> bug 1988843
[16:31] -ubottu:#ubuntu-meeting- Bug 1988843 in openjdk-lts (Ubuntu) "Eclipse IDE crashing with Java errors since 22.04 upgrade when using wayland" [High, Confirmed] https://launchpad.net/bugs/1988843
[16:33] <jawn-smith> samir has agreed to look into this
[16:33] <jawn-smith> bug 1990196
[16:33] -ubottu:#ubuntu-meeting- Bug 1990196 in ubiquity (Ubuntu Kinetic) "oem-config-kde crashes when buttons clicked" [High, Confirmed] https://launchpad.net/bugs/1990196
[16:35] <jawn-smith> ogayot to investigate, thanks!
[16:35] <jawn-smith> bug 1990535
[16:35] -ubottu:#ubuntu-meeting- Bug 1990535 in ubiquity (Ubuntu Jammy) "nvidia-settings not installed after off-line install of kinetic" [High, Confirmed] https://launchpad.net/bugs/1990535
[16:40] <jawn-smith> While steve looks at that I'll move on
[16:40] <jawn-smith> bug 1990964
[16:40] -ubottu:#ubuntu-meeting- Bug 1990964 in strace (Ubuntu) "FTBFS on kinetic" [High, Triaged] https://launchpad.net/bugs/1990964
[16:40] <jawn-smith> adrien: this is assigned to you in Jira
[16:41] <jawn-smith> adrien to assign himself the LP bug
[16:41] <jawn-smith> bug 1992159
[16:41] -ubottu:#ubuntu-meeting- Bug 1992159 in glibc (Ubuntu) "Syntax error defien in socket.h" [High, Triaged] https://launchpad.net/bugs/1992159
[16:42] <adrien> assigned the strace FTBFS to myself
[16:42] <jawn-smith> gblic is usually an mwhudson thing, right?
[16:43] <jawn-smith> I'll follow up with him about that
[16:44] <jawn-smith> That's all of the high priority bugs
[16:44] <jawn-smith> #topic AOB
[16:44] <jawn-smith> Many americans will be out next week
[16:44] <jawn-smith> I'll be off Thursday and Friday
[16:44] <enr0n> I will also be off Thursday and Friday
[16:45] <vorlon>  I'm off all next week
[16:45] <vorlon> takes time to digest turkey
[16:45] <bdrung> I'll be off half of Friday and full Monday
[16:46] <jawn-smith> New hire starting next week \o/
[16:46] <jawn-smith> So should we still have this meeting next week?
[16:47] <jawn-smith> We'll ping sil2100 to see if he can run it
[16:47] <jawn-smith> #endmeeting
[16:47] <meetingology> Meeting ended at 16:47:34 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-11-17-16.01.moin.txt


[00:39] <androidbruce> seattlegaucho, yes
[00:40] <androidbruce> seattlegaucho, i just took a job that uses MS SQL daily
[00:40] <androidbruce> so i was curious if you could shed some light
[00:42] <seattlegaucho> not really ... we have a SQL server here ... but we stay away from it like the plague
[01:17] <androidbruce> seattlegaucho, are queries similar?
[01:17] <seattlegaucho> SQL is mostly standard, so unless you get into stored procedures and stuff they should be similr
[01:21] <androidbruce> seattlegaucho, ok so anywhere you can point me to learn queries?
[01:21] <androidbruce> how to "grep" a database
[01:21] <seattlegaucho> that's a toughie
[01:21] <seattlegaucho> any introductory SQL book should work ... however ...
[01:22] <seattlegaucho> you need to learn how to check the 'database' and 'table' definitions, which is specific to SQL server
[01:23] <seattlegaucho> in MySQL it would be "SHOW DATABASES", "SHOW TABLES" and "SHOW CREATE TABLES" ... or there is another one: DESCRIBE ...
[01:23] <seattlegaucho> look for the equivalents on SQL Server
[01:24] <seattlegaucho> that will give you a basic understanding of the structure and from then on you can use SELECT to start making sense of the data
[01:24] <androidbruce> seattlegaucho, i see ok
[01:24] <androidbruce> with SQL Server, i can see everything graphically
[01:25] <androidbruce> so i've been failing, but using select * ........."User".......... etc etc
[01:53] <seattlegaucho> GUI is OK ... although it helps to understand what's going on underneath
[01:53] <seattlegaucho> ... need to go home ... I'll catch up w/ you tomorrow
[17:04]  * seattlegaucho waves to the crowds
[21:53]  * seattlegaucho had to crack open the only sql server screen active at his company
[21:53]  * seattlegaucho blames androidbruce for invoking the demons


[19:03] <StanAngeloff> Hey, anyone available to assist with Ubuntu Mobile SDK/Qt5?
[19:04] <StanAngeloff> I believe the current instructions to use Qt5-beta1 are a bit out-of-date.
[20:24] <mrbojangles3> Hi all, I am trying to install a kernel package. I have a udeb built but the driver is not getting copied in to the initrd. I have made a "normal" deb of the package and added it to the usb that i use to load the udeb, but the installer does not pickup the deb version for the initrd


[01:59] <hendry> oh yes, /srv/cdimage.no-name-yet.com/debian-cd/data/dapper/preseed
[02:13] <hendry> Kamion: do you have time to explain what pool/local is about? Is that a place to throw in additional packages?
[09:48] <drew> is it possible to make boot scripts interactive? #!/bin/bash -i doesn't seem to work...
[11:25] <Kamion> hendry: yes, it's for temporary hacks
[11:29] <hendry> Kamion: does it need to be main/binary-i386 format?
[11:30] <Kamion> I use the usual pool/ format of a Debian mirror, but honestly (a) I don't use it any more and you should avoid using it too if you possibly can, (b) I suspect the format does not actually matter
[11:31] <hendry> Kamion: ok


[14:56] <lotuspsychje> webchat60: openjdk had a recent update on noble
[14:59] <lotuspsychje> webchat60: 2024-01-24 17:35:18 upgrade openjdk-17-jre:amd64 17.0.10~6ea-1 17.0.10+7-1
[15:00] <lotuspsychje> we will have to await final release to find out
[20:24] <ChmEarl> noble roadmap says Jan 25 brings python3 3.12 as default, but its still 3.11
[22:54] <guiverc> ChmEarl, the transition is happening right now; did you see the update https://discourse.ubuntu.com/t/24-04-feature-freeze-and-transitions/41948   but plans & reality can often differ by a few days; we're not at freeze yet.
[22:55] <guiverc> "The Python 3.12 by default transition is going on right now. If you have affected packages.."


[05:16] <haobug> hi there,
[05:17] <haobug> i am trying the make launchpad to run on my own server. but i didn't found a step by step guide to do so. can any on help me out ?
[05:21] <wgrant> haobug: https://dev.launchpad.net/Running is just about all there is.
[05:24] <haobug> wgrant:does bzr --no-plugins line download from remote again. i have already downloaded the source. can i make use of that?
[05:28] <wgrant> haobug: To avoid redownloading it, run 'mkdir ~/launchpad; bzr init-repo ~/launchpad/lp-branches; bzr branch /PATH/TO/YOUR/LOCAL/BRANCH ~/launchpad/lp-branches/temp', then run ~/launchpad/lp-branches/temp/utilities/rocketfuel-setup and follow the instructions from 'Building' on that page.
[05:34] <haobug> wgrant: i know know so much about bazzer, it seems 'bzr branch/checkout' are making a copy of the original directory. that looks strange.
[05:35] <haobug> sorry, i don't know so much about bazzer.
[05:37] <lifeless> What is bazzer ?
[05:38] <haobug> lifeless: sorry again, i mean Bazaar. miss-typed.
[05:39] <wgrant> haobug: That's right. I suggested that so it could pre-seed ~/launchpad/lp-branches with the data you downloaded earlier, to minimise the volume that rocketfuel-setup must download.
[05:49] <haobug> i have another question about Karma, what mathematics modal are based on the build that? it is the most intention of me to try out the launchpad all in one system.
[05:55] <haobug> let me make my question clean and short(for my poor English skill): what mathematics modal Karma point are based on?
[11:52] <cjwatson> As I understand the PostgreSQL docs, if I have "CONSTRAINT livefs__owner__distroseries__name__key UNIQUE (owner, distroseries, name)", I don't also need to do "CREATE INDEX livefs__owner__distroseries__name__idx ON LiveFS (owner, distroseries, name);" - is that right?
[11:52] <cjwatson> (http://www.postgresql.org/docs/9.1/static/indexes-unique.html)
[11:53] <wgrant> cjwatson: You shouldn't need to, no.
[11:54] <wgrant> The alternative is to "CREATE UNIQUE INDEX livefs__owner__distroseries__name__key ON LiveFS (owner, distroseries, name);" instead of using CONSTRAINT in the table definition.
[11:54] <wgrant> But it makes no difference for a new, empty table.
[11:56] <cjwatson> OK, thanks.  I'm really not very experienced at all with this.  Does http://paste.ubuntu.com/7351944/ look remotely sensible?
[11:56] <cjwatson> I don't know whether indices of lots of columns for this sort of thing (updated maybe tens of times per day) are useful
[11:57] <cjwatson> LiveFS.builds actually hits a couple more columns for ordering, which I don't know whether/how I should include
[12:02] <wgrant> It totally depends on the sorts of queries you're doing. Indices are pretty much just B-trees, so they have the performance characteristics you'd expect: early index columns should approximate the common query filters, and the query's sort columns must be a suffix of the index's columns.
[12:02] <wgrant> Do you have some example queries>?
[12:06] <cjwatson> http://bazaar.launchpad.net/~cjwatson/launchpad/livefs/view/head:/lib/lp/soyuz/model/livefs.py lines 97-146
[12:07] <wgrant> +-- LiveFS.getMedianBuildDuration
[12:07] <wgrant> +CREATE INDEX livefsbuild__livefs__das__finished__idx
[12:07] <wgrant> +    ON LiveFSBuild (livefs, distroarchseries, date_finished);
[12:07] <wgrant> That's usable, but would be more efficient with a DESC on the date_finished
[12:09] <cjwatson> Probably right in general, although the current code (which I cloned-and-hacked from sourcepackagerecipebuild) will not make effective use of that
[12:09] <cjwatson> http://bazaar.launchpad.net/~cjwatson/launchpad/livefs/view/head:/lib/lp/soyuz/model/livefsbuild.py#L248
[12:09] <wgrant> Ah, indeed, no DAS
[12:09] <wgrant> oh
[12:10] <wgrant> doesn't use last_completed_build?
[12:10] <wgrant> Er
[12:10] <wgrant> Does SPRB really do that?
[12:10] <cjwatson> You think it should just use the last one as an estimate?  That doesn't seem very robust in cases where we have builders of different speeds
[12:10] <cjwatson> It does
[12:10] <cjwatson> I assume that should be done with a postgres expression ...
[12:11] <wgrant> I don't even
[12:11] <wgrant> It shouldn't be done at all
[12:11] <wgrant> That's an unbounded set.
[12:11] <wgrant> At least take the last ten or something.
[12:12] <wgrant> Doing it in postgres (or just pulling back date_finished and date_started, rather than instantiating entire objects) would be more efficient, but it's still pointlessly inefficient.
[12:12] <wgrant> That first build 5 years ago isn't very interesting.
[12:12] <wgrant> The median of the last dozen might be.
[12:13] <cjwatson> mm, right.  can I slice in the usual way after doing an order_by?
[12:14] <wgrant> Yeah
[12:15] <wgrant> I'd store.find((LiveFSBuild.date_finished, LiveFSBuild.date_started), blah blah blah).order_by(Desc(LiveFSBuild.date_finished))[:10] or so
[12:15] <cjwatson> Right, makes sense
[12:17] <wgrant> Just pull back ten sets of two datetimes, rather than instantiating 3462 full SourcePackageRecipeBuilds just to pull those two fields out.
[12:25] <wgrant> Oh that's right, I was meant to be looking for sane indices, not crying over bad existing code.
[12:26] <wgrant> last_completed_build (if it should exist in the first place) wants (livefs, date_finished DESC). builds wants (livefs, GREATEST(date_started, date_finished) DESC, date_created DESC, id DESC). The requestBuild one is fine.
[12:27] <cjwatson> I was thinking of using last_completed_build from cdimage, but maybe that's wrong and it should be looking up a particular build
[12:27] <wgrant> getMedianBuildDuration post-rewrite wants (livefs, distroarchseries, date_finished DESC) WHERE date_finished IS NOT NULL
[12:27] <wgrant> last_completed_build doesn't know about DASes.
[12:27] <wgrant> So I don't think it's useful for cdimage.
[12:28] <cjwatson> A reasonable point
[12:28] <wgrant> I try.
[12:28] <cjwatson> Why wouldn't builds want archive in there too?
[12:29] <cjwatson> (Oh, in fact I think I came up with last_completed_build before it occurred to me that it might be clever to add version to LiveFSBuild ...)
[12:31] <wgrant> Because we're not filtering to a small subset of the archives, so adding the column to the index would serve mostly to make it useless for the sort. If I have an index on foo(bar, id) and do SELECT * FROM foo WHERE bar = 1 ORDER BY id LIMIT 10, the DB can just seek to bar in the index and read the first ten entries.
[12:32] <wgrant> If I have foo(bar, baz, id) and do SELECT * FROM foo WHERE bar = 1 AND baz != 2 ORDER BY id LIMIT 10, the DB has to seek to bar, then read through the index for every value of baz that isn't 2, compile a list of all of the rows, and then sort in memory to find the latest ten.
[12:33] <cjwatson> We are filtering to a small subset, namely one ...
[12:33] <wgrant>             LiveFSBuild.archive_id == Archive.id,
[12:33] <wgrant>             Archive._enabled == True,
[12:33] <wgrant> That's more than one.
[12:33] <cjwatson> Oh, er, idiot
[12:33] <cjwatson> Yes
[12:33] <cjwatson> OK, that makes sense then
[12:33] <wgrant> Though you probably do want a method that filters by archive.
[12:34] <wgrant> In that case, you'd always want one with (livefs, archive, SORT) instead of just (livefs, SORT)
[12:34] <cjwatson> I'm not sure where such a method would actually be exposed.
[12:34] <wgrant> But for the general case it's far more efficient to read the first maybe 20 rows until you find ten that have valid archives, rather than having to read every row for the interesting archives.
[12:34] <wgrant> A good question.
[12:35] <wgrant> LiveFS.getBuilds, probably. I'm not sure the builds property is actually valuable.
[12:35] <wgrant> getBuilds can take an optional archive, das, pocket, etc.
[12:35] <cjwatson> It's an API convenience, I think.
[12:36] <cjwatson> cdimage will probably just be looking at the one it gets back from requestBuild.
[12:37] <cjwatson> I haven't quite decided what LiveFS:+builds should look like yet
[12:37] <cjwatson> It could perhaps reasonably display .builds[:10] or so
[12:38] <cjwatson> Or just batchnav the whole of .builds
[12:38] <cjwatson> We'll certainly want to be able to go back and look at old logs, but I don't know that the effort of adding fancy filtering forms and the like would be worthwhile
[12:41] <cjwatson> Maybe by status and architecture, like DS:+builds, I guess
[12:41] <cjwatson> I guess I can fill in indices needed for browser code in a -1 DB patch
[12:44] <wgrant> Right, and we can apply indices live
[12:44] <wgrant> So you could do them in 40 separate patches and it wouldn't be a major stab-worthy inconvenience.
[12:49] <cjwatson> OK, so I'll do the file URLs API method, nuke last_completed_build, do the reasonably clear parts of the indices above, and then I think I should have something worth reviewing.  I plan to defer the garbo job to a subsequent branch since it isn't actually vital until we start doing a non-trivial number of builds.
[12:49] <wgrant> Yep
[12:49] <wgrant> And this branch is already quite large enough
[12:50] <cjwatson> Indeed
[12:54] <cjwatson> Hm, I wonder if I need to do some archiveuploader work here, since there's no .changes file
[12:58] <wgrant> cjwatson: Not archiveuploader, but something similar, yeah.
[12:59] <wgrant> This isn't a package upload, so there's no reason to involve archiveuploader.
[12:59] <wgrant> But we need to do the librarian upload asynchronously (as we should with TTBJs, but we sorta get away with it now because they're so rare).
[13:11] <cjwatson> Doesn't it need to go through process-upload --builds?
[13:11] <cjwatson> Which is basically a shim over archiveuploader ...
[13:12] <wgrant> Why does it need to do that?
[13:12] <wgrant> process-upload is used to process package uploads.
[13:12] <cjwatson> I thought that was responsible for pulling everything off the buildds
[13:13] <cjwatson> Or rather dealing with all the stuff the buildds have pushed to builddmaster
[13:13] <wgrant> It's up to the BFJB
[13:14] <wgrant> The base implementation of BFJB._handleStatus_OK (which really should be in some other mixin) pulls the files off the buildd into a temporary directory, performs some sanity checks, then throws them into incoming/ for process-upload to handle.
[13:14] <wgrant> It then sets the build status to UPLOADING
[13:14] <wgrant> process-upload eventually runs, processes the upload, and sets the status to FULLYBUILT
[13:14] <wgrant> TTBJs skip UPLOADING, and just go from BUILDING -> FULLYBUILT inside the BFJB
[13:14] <wgrant> We can't really do that for LFSBs, because the librarian upload will take A While™.
[13:15] <wgrant> So we need some other async job.
[13:15] <wgrant> But there's no reason to shoehorn that into archiveuploader, unless you really like changes files.
[13:15] <cjwatson> Right, which means I need something very like process-upload except that it processes all the files in the upload rather than needing a .changes file
[13:15] <wgrant> It's similar to the very top level of process-upload, indeed.
[13:15] <wgrant> But it has basically none of the checks.
[13:16] <cjwatson> It seemed that it might make more sense to make the .changes dependency in process-upload be dependent on the BFJB
[13:16] <cjwatson> But maybe that's ridiculously hard
[13:16] <wgrant> It just runs listdir to find pending uploads, then for each it: finds the build from the dir name, listdirs the upload dir, uploads the files to the librarian, and sets the build status.
[13:17] <wgrant> You could possibly abstract process-upload to only invoke archiveuploader in some circumstances, but that seems like a lot of refactoring for little gain.
[13:18] <cjwatson> It would be nice not to have to basically reimplement BFJB._handleStatus_OK except for the incoming dir name
[13:18] <cjwatson> I guess I could make archiveuploader ignore livefs jobs
[13:18] <wgrant> It also wouldn't be fatally hard to refactor _handleStatus_OK slightly to let you customise that easily.
[13:19] <cjwatson> True
[13:20] <wgrant> Note that this will change a bit once we have the 1SS buildd-master satellite. BFJBs will be thoroughly neutered, and all expensive work must be deferred to a later asynchronous cronjob. At that point I suspect that _handleStatus_OK will become totally generic and just dump files into a directory, and there'll be something like process-upload running over a directory of all types of build results. But I'm not sure it's worth you doing that ...
[13:21] <wgrant> ... restructuring as part of the already complicated livefs work.
[13:21] <wgrant> I'd use a separate cronjob on alphecca, probably using some refactored bits of process-upload's build integration.
[13:21] <wgrant> The only bit of archiveuploader that is relevant at all is the build handling bit of process-upload.
[13:23] <cjwatson> OK
[13:23] <cjwatson> Hopefully my to-do list will shorten at some point :)
[13:24] <wgrant> Indeed


[02:57] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Jammy 22.04.1] has been marked as ready
[03:30] -queuebot:#ubuntu-release- Unapproved: nftables (jammy-proposed/main) [1.0.2-1ubuntu2 => 1.0.2-1ubuntu3] (no packageset)
[05:18] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Jammy 22.04.1] has been marked as ready
[05:19] -queuebot:#ubuntu-release- New binary: librecast [amd64] (kinetic-proposed/universe) [0.5.1-4] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: librecast [ppc64el] (kinetic-proposed/universe) [0.5.1-4] (no packageset)
[05:27] -queuebot:#ubuntu-release- New binary: librecast [armhf] (kinetic-proposed/universe) [0.5.1-4] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: librecast [arm64] (kinetic-proposed/universe) [0.5.1-4] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: librecast [riscv64] (kinetic-proposed/universe) [0.5.1-4] (no packageset)
[05:57] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Jammy 22.04.1] has been marked as ready
[05:57] <tsimonq2> On behalf of the Lubuntu team, I've marked 22.04.1 as ready
[05:57] <arraybolt3[m]> \o/
[05:58] <arraybolt3[m]> Hey, if anyone's up for more testing, looks like Kylin got left behind.
[05:58] <arraybolt3[m]> I'm zsyncing the ISO now, but I'm not sure we want to rely on one guys somewhat hacked-together desktop for an entire flavor's worth of QA tests.
[06:00] <sil2100> o/
[06:01] <arraybolt3[m]> sil2100: oh, hi!
[06:01] <arraybolt3[m]> Uh... well I should probably repost what I just told Simon and Chris a bit ago:
[06:01] <sil2100> Any bad news so far?
[06:01] <arraybolt3[m]> Hey, if anyone's up for more testing, looks like Kylin got left behind. I'm zsyncing the ISO now, but I'm not sure we want to rely on one guys somewhat hacked-together desktop for an entire flavor's worth of QA tests.
[06:02] <arraybolt3[m]> No failures, just one flavor kinda has a big donut where the number of tests should be.
[06:02] <sil2100> Yeah, saw that
[06:02] <arraybolt3[m]> (Also there's some riscv64 stuff in Ubuntu that needs some help, I'm intending to do what I can with QEMU on my end.)
[06:02] <sil2100> I noticed kylin wasn't really quite active for .1 sadly, didn't see handsome_feng or other devs recently
[06:03] <sil2100> So generally I'd just appreciate basic smoketesting of kylin
[06:03] <sil2100> We already had test results for the kylin images previously and the delta between the two RCs is small
[06:03] <arraybolt3[m]> OK. I'm intending to just throw my NVIDIA desktop that's been doing all the heavy lifting today at it and see what happens.
[06:04] <sil2100> That would be sufficient, thanks!
[06:26] <sil2100> hm hmm, no one actually recorded any test results for the "Install UEFI SecureBoot nVidia" test case for Ubuntu Desktop!
[06:27] <arraybolt3[m]> That because I didn't do Secure Boot.
[06:28] <arraybolt3[m]> My desktop is weird - if I enable Secure Boot with my NVIDIA card, even the BIOS won't output anything to the screen, which makes it really seriously hard to disable secure boot later unless I want to take the card out. And I can only do that 60 or so times according to my hardware's ratings.
[06:28] <arraybolt3[m]> I'm not sure if Linux will output anything to the screen either. And of course there's problems navigating the boot menu to boot from USB, though I could probably hack my way through that by doing it blind.
[06:28] <arraybolt3[m]> Sorry. :(
[06:29] <sil2100> Oh my! No worries! I'd like the desktop team to perform the test and mark it anyway, but oh well
[06:44]  * sil2100 needs to go for a few errands now anyway, be back in a bit
[07:24] <ricotz> hello ubuntu-release, kinetic package builds requiring python are broken since yesterday due to python3-distutils being uninstallable
[07:59] -queuebot:#ubuntu-release- Unapproved: samtools-legacy (jammy-proposed/universe) [0.1.19+dfsg-5 => 0.1.19+dfsg-5ubuntu0.1] (no packageset)
[08:08] -queuebot:#ubuntu-release- Unapproved: samtools-legacy (focal-proposed/universe) [0.1.19-4 => 0.1.19-4ubuntu0.1] (no packageset)
[08:29] <arraybolt3[m]> sil2100: I really hope I don't ruin your day right now. I just hit a critical bug in Kylin.
[08:29] <arraybolt3[m]> I don't know if it's a regression or not, but it renders the OS virtually unusable on physical hardware for me.
[08:30] <arraybolt3[m]> When you first log in after the initial installation, the OS automatically changes the resolution of the screen to some preset resolution (I encountered this in VM testing). It turns out, that resolution has the potential to be out of the range of a monitor (like my 1600x900 monitor), resulting in no video output.
[08:30] <arraybolt3[m]> And it shows no signs of coming out of it on its own.
[08:31] <arraybolt3[m]> I can still switch to a TTY, however.
[08:34] <sil2100> wow
[08:35] <sil2100> arraybolt3[m]: do you still have time to check 22.04 release images?
[08:35] <sil2100> Worst case, we'll have to skip kylin for .1 :(
[08:35] <arraybolt3[m]> Switching to my Full HD monitor sorta halfway works.
[08:35] <arraybolt3[m]> Yes, I can test 22.04.
[08:36] <sil2100> A point-release day without a critical day is a wasted day! ;)
[08:36] <sil2100> s/critical day/critical bug/
[08:37] <arraybolt3[m]> Right? :(
[08:38] <arraybolt3[m]> I didn't even get to find out if the proprietary driver worked or not because the big screen I have won't let me set it to 30Hz on UKUI so it flashes like a strobe light and makes my eyes hurt. Can't help but think that's a seizure risk (though that part is probably my hardware's fault).
[08:40] <arraybolt3[m]> Flashing UKylin 22.04 now.
[08:48] <arraybolt3[m]> Is there some way to delay the point release for just one flavor? If we could delay Kylin for long enough to fix this bug and let everyone else go into .1 mode now, that seems like it would work out best for everyone involved. (This may be very silly, so if so feel free to just ignore me, but just in case it's helpful, that's my idea.)
[08:49] <arraybolt3[m]> Or is that what you mean by "skip Kylin for .1"?
[08:49] -queuebot:#ubuntu-release- Unapproved: tracker-miners (focal-proposed/main) [2.3.3-2 => 2.3.3-2ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[08:50] <arraybolt3[m]> Turns out this is not a regression. The exact same thing just happened to me with "Try Ubuntu Kylin" on 22.04.
[08:52] <sil2100> Ouch
[08:52] <schopin> sil2100: do you still need someone to do the nvidia secure boot test?
[08:53] <sil2100> Wonder what's going on with that. Since it's not a regression, I think we'll just have to 'go with it'. But I'm a bit sad that the kylin flavor team members weren't too involved in .1
[08:53] <sil2100> schopin: oh, if you have the cycles, yes please. I can basically report my findings too, though
[08:54] <sil2100> I just want to do a quick test with 22.04 images
[08:55] <arraybolt3[m]> Welp, I guess that pretty much renders Kylin untestable for me on my end unless I can dig up my missing HDMI cable from somewhere within the depths of The Cord Glob.
[08:55] <schopin> I wanted to test the new image for nvidia installs anyways, might as well do it with SB.
[08:55] <arraybolt3[m]> (Actually I can still do virtualized tests, would that be helpful?)
[09:00] <sil2100> arraybolt3[m]: a virtualized one would also be good, at least *any* smoke test in this case could be good. To see if it doesn't explode completely (besides what you encountered already!)
[09:00] <arraybolt3[m]> 👍
[09:04] <arraybolt3[m]> Also if anyone has an NVIDIA card and a Full HD screen, that would probably also work for Kylin testing if we're wanting to make sure NVIDIA is all good there.
[09:05] <sil2100> Oh, actually, nvidia-settings not pre-installed on offline install is not a regression!
[09:29] <arraybolt3[m]> I just realized something that may be helpful.
[09:30] <arraybolt3[m]> The one monitor I have is a 1600x900, but it seems to report that it supports Full HD when it doesn't.
[09:30] <arraybolt3[m]> And Kylin automatically sets itself to the highest supported resolution of a monitor.
[09:30] <arraybolt3[m]> So I think this is a hardware problem on my end, and that Kylin itself is probably OK.
[09:31] <arraybolt3[m]> (Though all the other flavors automatically selected the right resolution, so maybe Kylin needs to adopt the logic of the other flavors for detecting optimal screen resolution.)
[09:31] <arraybolt3[m]> I've encountered this before on Ubuntu Studio - it autoselects the right resolution but allows you to select the wrong one, and selecting the wrong one makes it go wonky.
[09:32] <sil2100> hm, I'll try to run a kylin test on my laptop just in case, but it depends how much time I'll have
[09:33] <arraybolt3[m]> At least I think it autoselects the highest supported resolution based on what it just did in my VM (it jumped to some 2000+ pixel resolution).
[09:33] <sil2100> I know utkarsh2102 is also doing some kylin testing
[09:35] <sil2100> All in all, I think we're good to go. I'll wait for final kylin smoke tests but in the meantime work on starting the release process
[09:36] <arraybolt3[m]> My smoke test seems to be OK - Firefox is working out of the box and I was able to set a lower screen resolution. The Settings app crashed on me but was still functional (I didn't even know it had crashed until looking at the taskbar and noticing a crash warning, it must have crashed upon closing).
[09:57] <sil2100> Thanks!
[09:58] <sil2100> Ok, marking some flavors as ready. I see mate is all green, marking that one as well!
[09:58] <sil2100> Server looking good too
[09:58] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Jammy 22.04.1] has been marked as ready
[09:58] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Jammy 22.04.1] has been marked as ready
[09:58] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Jammy 22.04.1] has been marked as ready
[09:58] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Jammy 22.04.1] has been marked as ready
[09:58] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Jammy 22.04.1] has been marked as ready
[09:58] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Jammy 22.04.1] has been marked as ready
[09:58] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Jammy 22.04.1] has been marked as ready
[09:58] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Jammy 22.04.1] has been marked as ready
[09:58] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity riscv64 [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+nezha [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unmatched [Jammy 22.04.1] has been marked as ready
[09:59] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+visionfive [Jammy 22.04.1] has been marked as ready
[10:04] <sil2100> Ok everyone, let's release .1! I'll mark kylin as ready as I think it's 'as ready as it can'
[10:05] <arraybolt3[m]> \o/ :=1
[10:05] <arraybolt3[m]> 👍
[10:05] <arraybolt3[m]> (Thanks Matrix for letting me accidentally send a nonsensical :=1 when I meant to send 👍...)
[10:05] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Jammy 22.04.1] has been marked as ready
[10:05] <arraybolt3[m]> (I guess that's actually my typo's fault though, whatever.)
[10:07] <sil2100> :D
[10:11] <arraybolt3[m]> sil2100: Will it wreak everything for me to submit a failed result on the ISO tracker? I was just about to do that to document my findings, but I don't want to do that if it's going to mess anything up.
[10:14] <RikMills> \o/
[10:15] <RikMills> sil2100: the next thing people will be bound to ask is..... will do-release-upgrades be turned on before the weekend?
[10:15]  * RikMills hides
[10:15] <arraybolt3[m]> Eh, they're asking that already :D
[10:15] <RikMills> I know, but that will multiply with the .1 out!
[10:16] <sil2100> RikMills: yes! We want to turn it on today!
[10:17] <RikMills> \o/^2
[10:17]  * arraybolt3[m] prepares for the onslaught of failed do-release-upgrade support requests
[10:18] <arraybolt3[m]> Whew, we're done! Woot! Anything else that needs done, and also, should I submit the one failed test for the mess I had with my one weird monitor?
[10:19] <RikMills> arraybolt3[m]: I am hoping for a repeat of this: https://www.dedoimedo.com/computers/kubuntu-impish-jammy-upgrade.html
[10:21] <arraybolt3[m]> Wow, that's awesome.
[10:22] <RikMills> especially since he is a very picky... ummmm..... person
[10:27] <sil2100> Okay, prep work done, now doing the actual publishing (mirrors still disabled)
[11:10] <sil2100> Switching mirror sync in a moment!
[11:24] <sil2100> 22.04.1 should be syncing now
[12:11] <sil2100> \o/
[12:11] <sil2100> I'll be sending out the announement e-mail in a bit
[12:28] <Maik> OMG!Ubuntu seems to be ruin it again, they already posted it's available for download, while it's not. Isn't there some way to stop that guy from posting releases ahead of the official announcement and when the mirrors have been synced?
[12:32] <ahasenack> hi ubuntu-archive, src:openfst has some new binaryes due to a soname change, could someone please take a look at the kinetic NEW queue?
[12:38] <cjwatson> Maik: I remember trying that more than a decade ago and got nowhere
[12:44] <xnox> Maik:  the solution was for us to close the public end points of cdimage/releases; but only maintain rsync access for mirrors. But that requires IS to implement such a curtain. All other major distributors do that. I.e. apple.com goes into maintainance mode curtain during their announcement days, until new websites/webstores/downloads are deployed and then they lift the frontend curtain.
[12:48] <Maik> cjwatson: yeah, he seems to be stubborn on that part and just wants the click counts for his website.
[12:49] <cjwatson> I think the answer is just to make our peace with the fact that journalists want clicks, TBH
[12:50] <cjwatson> Apple are uhh not especially reliant on a community working on the OS itself
[12:51] <cjwatson> And it's much less of a problem than it was in the old days, where the load from early announcements sometimes made it difficult for us to actually finish the release
[12:52] <sil2100> hm hm, I'm getting 503's when trying to fetch things from the librarian, anyone else seeing this as well?
[12:52] <sil2100> Or is it just me?
[12:53] <rbasak> sil2100: current outage
[12:54] <cjwatson> yeah, a PS5 node went down
[12:57] <jbicha> sil2100: I created the redirect at https://wiki.ubuntu.com/JammyJellyfish/ReleaseNotes/ChangeSummary/22.04.1
[12:57] <sil2100> jbicha: thanks! Are we linking that somewhere?
[12:57] <jbicha> https://wiki.ubuntu.com/Releases
[12:58] <sil2100> Ah, yes, forgot about that one
[12:58] <jbicha> maybe we can add an extra step to the checklist then
[13:00] <ernstp> ah there's already a user-agent update on master!
[13:01] <ernstp> sorry, wrong channel
[13:32] <tjaalton> sil2100: congrats on the release :) do you plan to flush SRU's to jammy-updates? linux-firmware is what I'm interested in
[13:37] <mdeslaur> woo-hoo, congrats :)
[13:59] <ricotz> hello, could someone please sort out the "python3-stdlib-extensions - python3-defaults" conflict in kinetic?
[14:07] <ahasenack> ricotz: I think thumbleweed is taking a look, see #ubuntu-devel
[14:08] <ahasenack> I also have a bunch of migrations and builds waiting on that
[14:10] <sil2100> tjaalton: hey! Thanks! Yesss, I'll do some flushing during my quick-shift later today, after some meeting
[14:10] <sil2100> 's
[14:11] <ricotz> ahasenack, ah, I see, basically reverting the dependency bump in python3-stdlib-extensions would be sufficient
[14:11] <ricotz> ahasenack, and yeah, this breaks e.g. firefox/libreoffice builds
[14:13] <tjaalton> sil2100: excellent, thanks
[14:24] <sil2100> bdmurray: can you switch updates today?
[14:25] <sil2100> *switch updates on today
[14:26] <bdmurray> Yes, I'm actively working on it.
[14:26] <bdmurray> Well upgrades not updates. ;-)
[14:27] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (bionic-proposed/main) [2.04-1ubuntu44.1.2 => 2.04-1ubuntu47.4] (no packageset) (sync)
[14:27] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (focal-proposed/main) [2.04-1ubuntu44.2 => 2.04-1ubuntu47.4] (no packageset) (sync)
[14:27] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (jammy-proposed/main) [2.06-2ubuntu7 => 2.06-2ubuntu10] (core, i386-whitelist) (sync)
[14:28] <sil2100> bdmurray: yes, that! ;)
[15:15] <icey[m]> hey, now that 22.04.1 is out, is the SRU queue ready to unstick?
[15:18] <sil2100> Hey! Yes! But there's a bit of a backlog
[15:18] <sil2100> I'll do a few reviews and flush the ready-for-publishing later today
[15:18] -queuebot:#ubuntu-release- Unapproved: accepted tracker-miners [source] (focal-proposed) [2.3.3-2ubuntu<IP_ADDRESS>]
[15:42] <sil2100> Okay, so my publish shift will be a bit 'wonky' today as the report is incomplete due to the LP issues earlier
[15:56] <rbasak> sil2100: just checking jammy-proposed/-updates are open again now please?
[15:56] <rbasak> I have a bunch of ua-tools to accept into proposed
[15:56] <sil2100> rbasak: yes!
[15:56] <sil2100> Please proceed
[16:04] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (jammy-proposed) [27.10.1~22.04.1]
[16:04] <rbasak> Thanks!
[16:05] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (bionic-proposed) [27.10.1~18.04.1]
[16:05] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (focal-proposed) [27.10.1~20.04.1]
[16:05] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (xenial-proposed) [27.10.1~16.04.1]
[16:16] -queuebot:#ubuntu-release- New binary: nautilus [amd64] (kinetic-proposed/main) [1:43~beta.1-2ubuntu1] (ubuntu-desktop)
[16:16] -queuebot:#ubuntu-release- New binary: nautilus [ppc64el] (kinetic-proposed/main) [1:43~beta.1-2ubuntu1] (ubuntu-desktop)
[16:19] -queuebot:#ubuntu-release- New binary: poppler [i386] (kinetic-proposed/main) [22.08.0-1] (desktop-core, i386-whitelist, ubuntu-server)
[16:20] -queuebot:#ubuntu-release- New binary: poppler [amd64] (kinetic-proposed/main) [22.08.0-1] (desktop-core, i386-whitelist, ubuntu-server)
[16:22] -queuebot:#ubuntu-release- New binary: poppler [ppc64el] (kinetic-proposed/main) [22.08.0-1] (desktop-core, i386-whitelist, ubuntu-server)
[16:23] -queuebot:#ubuntu-release- New binary: nautilus [arm64] (kinetic-proposed/main) [1:43~beta.1-2ubuntu1] (ubuntu-desktop)
[16:23] -queuebot:#ubuntu-release- New binary: nautilus [armhf] (kinetic-proposed/main) [1:43~beta.1-2ubuntu1] (ubuntu-desktop)
[16:30] -queuebot:#ubuntu-release- New binary: poppler [armhf] (kinetic-proposed/main) [22.08.0-1] (desktop-core, i386-whitelist, ubuntu-server)
[16:33] -queuebot:#ubuntu-release- New binary: poppler [arm64] (kinetic-proposed/main) [22.08.0-1] (desktop-core, i386-whitelist, ubuntu-server)
[16:33] <RikMills> I see jammy in https://changelogs.ubuntu.com/meta-release-lts
[16:33] <RikMills> \0/
[16:35] <bdmurray> yep
[16:54] <RikMills> tried upgrade of a clean lxd container. once ubuntu-release-upgrader-core was installed, do-release-upgrade crashed complaining lspci was not found. so had to install pciutils to make it work
[16:55] <RikMills> I guess we have a dependency issue there
[16:55] -queuebot:#ubuntu-release- New binary: nautilus [riscv64] (kinetic-proposed/main) [1:43~beta.1-2ubuntu1] (ubuntu-desktop)
[16:55] <bdmurray> RikMills: can you open a bug with a Traceback?
[16:55] <RikMills> bdmurray: sure
[17:05] <RikMills> bdmurray: LP: #1985253
[17:06] <RikMills> duh 20.04
[17:06] <RikMills> title fixed
[17:11] <bdmurray> jbicha: the release checklists can be found at https://code.launchpad.net/~ubuntu-release/ubuntu-release-tools/+git/templates/+ref/main if you want to submit a PR re the wiki pages and changelogs
[17:19] -queuebot:#ubuntu-release- New binary: libsoftware-copyright-perl [amd64] (kinetic-proposed/universe) [0.004-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: poppler [riscv64] (kinetic-proposed/main) [22.08.0-1] (desktop-core, i386-whitelist, ubuntu-server)
[17:36] <bdmurray> sil2100: Could you fully phase snapd as it was included on the 22.04.1 images? It's already at 90%
[18:01] -queuebot:#ubuntu-release- Unapproved: cinder (jammy-proposed/main) [2:20.0.0-0ubuntu1 => 2:20.0.1-0ubuntu1] (openstack)
[18:03] -queuebot:#ubuntu-release- Unapproved: pyroute2 (jammy-proposed/main) [0.6.4-3 => 0.6.4-3ubuntu1] (no packageset)
[18:04] -queuebot:#ubuntu-release- Unapproved: neutron (jammy-proposed/main) [2:20.1.0-0ubuntu2 => 2:20.2.0-0ubuntu1] (openstack)
[19:17] <icey[m]> any chance on getting python-cheroot accepted into jammy-proposed?
[19:37] -queuebot:#ubuntu-release- New binary: nautilus [s390x] (kinetic-proposed/main) [1:43~beta.1-2ubuntu1] (ubuntu-desktop)
[19:47] -queuebot:#ubuntu-release- New binary: poppler [s390x] (kinetic-proposed/main) [22.08.0-1] (desktop-core, i386-whitelist, ubuntu-server)
[20:05] -queuebot:#ubuntu-release- New binary: librecast [s390x] (kinetic-proposed/universe) [0.5.1-4] (no packageset)
[20:13] <sil2100> bdmurray: ok!
[20:14] -queuebot:#ubuntu-release- Unapproved: gnome-control-center (jammy-proposed/main) [1:41.7-0ubuntu<IP_ADDRESS> => 1:41.7-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[20:15] <sil2100> bdmurray: oh, in the meantime it managed to fully phase already I guess :(
[20:42] <bdmurray> sil2100: Do you think we should do an early release of cryptsetup for bug 1979159?
[20:42] <sil2100> bdmurray: it's a possibility, I feel like it's something we could consider
[20:42] <sil2100> bdmurray: can you do that?
[20:43] <bdmurray> sil2100: Yeah, I'm looking at the diff now
[21:09] -queuebot:#ubuntu-release- New binary: fence-agents [amd64] (kinetic-proposed/main) [4.11.0-1ubuntu1] (ubuntu-server)
[21:09] -queuebot:#ubuntu-release- New binary: fence-agents [ppc64el] (kinetic-proposed/main) [4.11.0-1ubuntu1] (ubuntu-server)
[21:14] -queuebot:#ubuntu-release- New binary: fence-agents [arm64] (kinetic-proposed/main) [4.11.0-1ubuntu1] (ubuntu-server)
[21:14] -queuebot:#ubuntu-release- New binary: fence-agents [armhf] (kinetic-proposed/main) [4.11.0-1ubuntu1] (ubuntu-server)
[21:53] -queuebot:#ubuntu-release- New binary: fence-agents [riscv64] (kinetic-proposed/main) [4.11.0-1ubuntu1] (ubuntu-server)
[21:55] -queuebot:#ubuntu-release- New source: golang-github-marten-seemann-qtls-go1-19 (kinetic-proposed/primary) [0.1.0-0ubuntu1]
[22:07] -queuebot:#ubuntu-release- Unapproved: backuppc (focal-proposed/main) [3.3.2-3 => 3.3.2-3ubuntu0.1] (core)
[22:11] -queuebot:#ubuntu-release- Unapproved: gnome-shell (jammy-proposed/main) [42.2-0ubuntu0.2 => 42.4-0ubuntu<IP_ADDRESS>] (desktop-extra, mozilla, ubuntu-desktop)
[22:55] -queuebot:#ubuntu-release- Unapproved: backuppc (bionic-proposed/main) [3.3.1-4ubuntu1 => 3.3.1-4ubuntu1.1] (core)
[23:21] -queuebot:#ubuntu-release- New binary: libtickit-widget-entry-plugin-completion-perl [amd64] (kinetic-proposed/universe) [0.01-2] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: pass-otp [amd64] (kinetic-proposed/universe) [1.2.0-3] (lubuntu)
[23:22] -queuebot:#ubuntu-release- New binary: libtickit-app-plugin-escapeprefix-perl [amd64] (kinetic-proposed/universe) [0.02-2] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: raku-json-name [amd64] (kinetic-proposed/universe) [0.0.7-3] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: pgpainless [amd64] (kinetic-proposed/universe) [1.3.5-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: raku-json-name [ppc64el] (kinetic-proposed/universe) [0.0.7-3] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-block-buffer-0.9 [amd64] (kinetic-proposed/none) [0.9.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-multibase [amd64] (kinetic-proposed/none) [0.8.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: phosh-mobile-settings [amd64] (kinetic-proposed/none) [0.20.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-digest-0.9 [amd64] (kinetic-proposed/none) [0.9.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-arrayvec-0.5 [amd64] (kinetic-proposed/none) [0.5.2-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-quick-protobuf [amd64] (kinetic-proposed/none) [0.7.0-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: rust-arrayvec-0.5 [ppc64el] (kinetic-proposed/none) [0.5.2-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: rust-multibase [ppc64el] (kinetic-proposed/none) [0.8.0-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: phosh-mobile-settings [ppc64el] (kinetic-proposed/none) [0.20.0-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: rust-quick-protobuf [ppc64el] (kinetic-proposed/none) [0.7.0-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: rust-block-buffer-0.9 [ppc64el] (kinetic-proposed/none) [0.9.0-1] (no packageset)
[23:29] -queuebot:#ubuntu-release- New binary: rust-digest-0.9 [ppc64el] (kinetic-proposed/none) [0.9.0-1] (no packageset)
[23:31] -queuebot:#ubuntu-release- New: accepted anonip [amd64] (kinetic-proposed) [1.1.0-1]
[23:31] -queuebot:#ubuntu-release- New: accepted gnome-epub-thumbnailer [arm64] (kinetic-proposed) [1.6-2]
[23:31] -queuebot:#ubuntu-release- New: accepted gnome-epub-thumbnailer [ppc64el] (kinetic-proposed) [1.6-2]
[23:31] -queuebot:#ubuntu-release- New: accepted gnome-epub-thumbnailer [s390x] (kinetic-proposed) [1.6-2]
[23:31] -queuebot:#ubuntu-release- New: accepted haskell-language-c99-simple [ppc64el] (kinetic-proposed) [0.1.2-2]
[23:31] -queuebot:#ubuntu-release- New: accepted libcommuni [amd64] (kinetic-proposed) [3.7.0-1]
[23:31] -queuebot:#ubuntu-release- New: accepted libcommuni [ppc64el] (kinetic-proposed) [3.7.0-1]
[23:31] -queuebot:#ubuntu-release- New: accepted gnome-epub-thumbnailer [amd64] (kinetic-proposed) [1.6-2]
[23:31] -queuebot:#ubuntu-release- New: accepted gnome-epub-thumbnailer [riscv64] (kinetic-proposed) [1.6-2]
[23:31] -queuebot:#ubuntu-release- New: accepted haskell-language-c99-simple [s390x] (kinetic-proposed) [0.1.2-2]
[23:31] -queuebot:#ubuntu-release- New: accepted libcommuni [s390x] (kinetic-proposed) [3.7.0-1]
[23:31] -queuebot:#ubuntu-release- New: accepted gnome-epub-thumbnailer [armhf] (kinetic-proposed) [1.6-2]
[23:31] -queuebot:#ubuntu-release- New: accepted libcommuni [armhf] (kinetic-proposed) [3.7.0-1]
[23:31] -queuebot:#ubuntu-release- New: accepted haskell-language-c99-simple [arm64] (kinetic-proposed) [0.1.2-2]
[23:32] -queuebot:#ubuntu-release- New: accepted haskell-language-c99-simple [riscv64] (kinetic-proposed) [0.1.2-2]
[23:32] -queuebot:#ubuntu-release- New: accepted interception-tools [arm64] (kinetic-proposed) [0.6.8-1]
[23:32] -queuebot:#ubuntu-release- New: accepted interception-tools [ppc64el] (kinetic-proposed) [0.6.8-1]
[23:32] -queuebot:#ubuntu-release- New: accepted interception-tools [s390x] (kinetic-proposed) [0.6.8-1]
[23:32] -queuebot:#ubuntu-release- New: accepted libcommuni [riscv64] (kinetic-proposed) [3.7.0-1]
[23:32] -queuebot:#ubuntu-release- New: accepted libcommuni [arm64] (kinetic-proposed) [3.7.0-2]
[23:32] -queuebot:#ubuntu-release- New: accepted libcommuni [ppc64el] (kinetic-proposed) [3.7.0-2]
[23:32] -queuebot:#ubuntu-release- New: accepted libcommuni [s390x] (kinetic-proposed) [3.7.0-2]
[23:32] -queuebot:#ubuntu-release- New: accepted librecast [arm64] (kinetic-proposed) [0.5.1-3]
[23:32] -queuebot:#ubuntu-release- New: accepted librecast [ppc64el] (kinetic-proposed) [0.5.1-3]
[23:32] -queuebot:#ubuntu-release- New: accepted interception-tools [amd64] (kinetic-proposed) [0.6.8-1]
[23:32] -queuebot:#ubuntu-release- New: accepted interception-tools [riscv64] (kinetic-proposed) [0.6.8-1]
[23:32] -queuebot:#ubuntu-release- New: accepted libcommuni [amd64] (kinetic-proposed) [3.7.0-2]
[23:32] -queuebot:#ubuntu-release- New: accepted libcommuni [riscv64] (kinetic-proposed) [3.7.0-2]
[23:32] -queuebot:#ubuntu-release- New: accepted librecast [armhf] (kinetic-proposed) [0.5.1-3]
[23:32] -queuebot:#ubuntu-release- New: accepted librecast [s390x] (kinetic-proposed) [0.5.1-3]
[23:32] -queuebot:#ubuntu-release- New: accepted librecast [arm64] (kinetic-proposed) [0.5.1-4]
[23:32] -queuebot:#ubuntu-release- New: accepted librecast [ppc64el] (kinetic-proposed) [0.5.1-4]
[23:32] -queuebot:#ubuntu-release- New: accepted librecast [s390x] (kinetic-proposed) [0.5.1-4]
[23:32] -queuebot:#ubuntu-release- New: accepted libtickit-app-plugin-escapeprefix-perl [amd64] (kinetic-proposed) [0.02-1]
[23:32] -queuebot:#ubuntu-release- New: accepted interception-tools [armhf] (kinetic-proposed) [0.6.8-1]
[23:32] -queuebot:#ubuntu-release- New: accepted libcommuni [armhf] (kinetic-proposed) [3.7.0-2]
[23:32] -queuebot:#ubuntu-release- New: accepted librecast [riscv64] (kinetic-proposed) [0.5.1-3]
[23:32] -queuebot:#ubuntu-release- New: accepted librecast [armhf] (kinetic-proposed) [0.5.1-4]
[23:32] -queuebot:#ubuntu-release- New: accepted libsoftware-copyright-perl [amd64] (kinetic-proposed) [0.004-1]
[23:32] -queuebot:#ubuntu-release- New: accepted libtickit-widget-entry-plugin-completion-perl [amd64] (kinetic-proposed) [0.01-1]
[23:32] -queuebot:#ubuntu-release- New: accepted pass-otp [amd64] (kinetic-proposed) [1.2.0-3]
[23:32] -queuebot:#ubuntu-release- New source: ivsc-driver (kinetic-proposed/primary) [0~git202205110052.b8c22f42-0ubuntu1]
[23:32] -queuebot:#ubuntu-release- New binary: renpy [amd64] (kinetic-proposed/universe) [8.0.1+dfsg-1] (no packageset)
[23:32] -queuebot:#ubuntu-release- New: accepted libcommuni [arm64] (kinetic-proposed) [3.7.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted librecast [amd64] (kinetic-proposed) [0.5.1-4]
[23:33] -queuebot:#ubuntu-release- New: accepted libtickit-app-plugin-escapeprefix-perl [amd64] (kinetic-proposed) [0.02-2]
[23:33] -queuebot:#ubuntu-release- New source: ipu6-drivers (kinetic-proposed/primary) [0~git202204270226.8357dee9-0ubuntu1]
[23:33] -queuebot:#ubuntu-release- New binary: python-ldap [amd64] (kinetic-proposed/main) [3.4.2-2] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: renpy [ppc64el] (kinetic-proposed/universe) [8.0.1+dfsg-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: secrets [amd64] (kinetic-proposed/universe) [6.5-2] (no packageset)
[23:33] -queuebot:#ubuntu-release- New: accepted librecast [amd64] (kinetic-proposed) [0.5.1-3]
[23:33] -queuebot:#ubuntu-release- New: accepted libtickit-widget-entry-plugin-completion-perl [amd64] (kinetic-proposed) [0.01-2]
[23:33] -queuebot:#ubuntu-release- New binary: renpy [armhf] (kinetic-proposed/universe) [8.0.1+dfsg-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New source: virtualbmc (kinetic-proposed/primary) [2.2.2-0ubuntu1]
[23:33] -queuebot:#ubuntu-release- New: accepted phosh-mobile-settings [amd64] (kinetic-proposed) [0.20.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted poppler [amd64] (kinetic-proposed) [22.08.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted poppler [armhf] (kinetic-proposed) [22.08.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted poppler [ppc64el] (kinetic-proposed) [22.08.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted poppler [s390x] (kinetic-proposed) [22.08.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted raku-json-name [amd64] (kinetic-proposed) [0.0.7-3]
[23:33] -queuebot:#ubuntu-release- New: accepted librecast [riscv64] (kinetic-proposed) [0.5.1-4]
[23:33] -queuebot:#ubuntu-release- New binary: renpy [s390x] (kinetic-proposed/universe) [8.0.1+dfsg-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New: accepted phosh-mobile-settings [ppc64el] (kinetic-proposed) [0.20.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted poppler [i386] (kinetic-proposed) [22.08.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted python-ldap [amd64] (kinetic-proposed) [3.4.2-2]
[23:33] -queuebot:#ubuntu-release- New: accepted renpy [amd64] (kinetic-proposed) [8.0.1+dfsg-1]
[23:33] -queuebot:#ubuntu-release- New: accepted renpy [armhf] (kinetic-proposed) [8.0.1+dfsg-1]
[23:33] -queuebot:#ubuntu-release- New: accepted renpy [riscv64] (kinetic-proposed) [8.0.1+dfsg-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-arrayvec-0.5 [amd64] (kinetic-proposed) [0.5.2-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-block-buffer-0.9 [amd64] (kinetic-proposed) [0.9.0-1]
[23:33] -queuebot:#ubuntu-release- New source: lubuntu-installer-prompt (kinetic-proposed/primary) [0.2.0-0ubuntu1]
[23:33] -queuebot:#ubuntu-release- New: accepted poppler [arm64] (kinetic-proposed) [22.08.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted raku-json-name [ppc64el] (kinetic-proposed) [0.0.7-3]
[23:33] -queuebot:#ubuntu-release- New: accepted renpy [ppc64el] (kinetic-proposed) [8.0.1+dfsg-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-arrayvec-0.5 [ppc64el] (kinetic-proposed) [0.5.2-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-digest-0.9 [amd64] (kinetic-proposed) [0.9.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-multibase [amd64] (kinetic-proposed) [0.8.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-quick-protobuf [amd64] (kinetic-proposed) [0.7.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted secrets [amd64] (kinetic-proposed) [6.5-2]
[23:33] -queuebot:#ubuntu-release- New: accepted pgpainless [amd64] (kinetic-proposed) [1.3.5-1]
[23:33] -queuebot:#ubuntu-release- New: accepted renpy [arm64] (kinetic-proposed) [8.0.1+dfsg-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-block-buffer-0.9 [ppc64el] (kinetic-proposed) [0.9.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-multibase [ppc64el] (kinetic-proposed) [0.8.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted poppler [riscv64] (kinetic-proposed) [22.08.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-digest-0.9 [ppc64el] (kinetic-proposed) [0.9.0-1]
[23:33] -queuebot:#ubuntu-release- New: accepted renpy [s390x] (kinetic-proposed) [8.0.1+dfsg-1]
[23:33] -queuebot:#ubuntu-release- New: accepted rust-quick-protobuf [ppc64el] (kinetic-proposed) [0.7.0-1]
[23:37] -queuebot:#ubuntu-release- New binary: raku-json-name [s390x] (kinetic-proposed/universe) [0.0.7-3] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-arrayvec-0.5 [riscv64] (kinetic-proposed/none) [0.5.2-1] (no packageset)
[23:40] -queuebot:#ubuntu-release- New binary: rust-block-buffer-0.9 [riscv64] (kinetic-proposed/none) [0.9.0-1] (no packageset)
[23:42] -queuebot:#ubuntu-release- New binary: phosh-mobile-settings [s390x] (kinetic-proposed/none) [0.20.0-1] (no packageset)
[23:43] -queuebot:#ubuntu-release- New binary: rust-arrayvec-0.5 [s390x] (kinetic-proposed/none) [0.5.2-1] (no packageset)
[23:47] -queuebot:#ubuntu-release- New: accepted phosh-mobile-settings [s390x] (kinetic-proposed) [0.20.0-1]
[23:47] -queuebot:#ubuntu-release- New: accepted rust-arrayvec-0.5 [riscv64] (kinetic-proposed) [0.5.2-1]
[23:47] -queuebot:#ubuntu-release- New: accepted rust-block-buffer-0.9 [riscv64] (kinetic-proposed) [0.9.0-1]
[23:47] -queuebot:#ubuntu-release- New: accepted raku-json-name [s390x] (kinetic-proposed) [0.0.7-3]
[23:47] -queuebot:#ubuntu-release- New: accepted rust-arrayvec-0.5 [s390x] (kinetic-proposed) [0.5.2-1]