[02:01] <sergiusens> robru: can you help me out with https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/146/console ?
[02:04] <imgbot> [02:17] <rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch
[02:17] <rsalveti> sergiusens: dual changes are not yet in release
[02:17] <rsalveti> and the other MR is probably not yet merged
[02:18] <rsalveti> actually, no
[02:18] <rsalveti> weird, an older version is stuck in proposed
[02:18] <rsalveti> how could that happen
[02:18] <sergiusens> rsalveti: I don't know...
[02:19] <rsalveti> sergiusens: both seems to be the same upload
[02:19] <rsalveti> https://launchpadlibrarian.net/191444158/goget-ubuntu-touch_0.5-0ubuntu1_0.4%2B15.04.20141128-0ubuntu1.diff.gz
[02:19] <sergiusens> rsalveti: hmm, seems someone "published" line 43 in the sheet
[02:19] <rsalveti> sergiusens: it seems train did 2 uploads at the same time?
[02:19] <sergiusens> rsalveti: but it was never set to testing yes :(
[02:19] <rsalveti> that is an interesting behavior
[02:19] <rsalveti> infinity: around?
[02:19] <rsalveti> infinity: if so, check https://launchpad.net/ubuntu/+source/goget-ubuntu-touch
[02:20] <rsalveti> sergiusens: hm, right
[02:20] <rsalveti> sergiusens: do you remember the ppa number for that one?
[02:21] <rsalveti> lp might say that
[02:21] <rsalveti> one is from ppa 03
[02:21] <sergiusens> 03
[02:21] <robru> sergiusens: ah, you should be able to just FORCE_REBUILD that silo and it'll plow over that other wrong version
[02:21] <rsalveti> and the other seems to be a dput?
[02:21] <rsalveti> sergiusens: did you do a dput manually?
[02:21] <sergiusens> rsalveti: yes, the train was broken on Friday
[02:21] <rsalveti> oh, right, then that explains one piece
[02:22] <robru> sergiusens: sorry I gotta run, but yeah after you dput'd I fixed up your silo and then did a normal publish. your dput "won" because of the higher version. should be safe to just disregard and force the build job
[02:22] <rsalveti> one interesting thing though is that the other upload (one in proposed) should, in theory, be refused by lp
[02:22] <sergiusens> robru: my dput won because it was 2 hours before ;-)
[02:22] <rsalveti> and that's clearly not the case
[02:22] <robru> sergiusens: that too ;-)
[02:22] <sergiusens> robru: and I didn't set 'testing' to yes either ;-)
[02:22] <robru> sergiusens: if you hadn't bumped the version though my secondary publish would have overwritten yours.
[02:24] <rsalveti> guess because the upload done by the train is actually a package sync
[02:24] <rsalveti> still, maybe we just found a race, not sure
[02:24] <rsalveti> an archive admin should be able to give a proper answer
[02:25] <robru> rsalveti: shouldn't be a race, I manually triggered a publish there.
[02:25] <rsalveti> robru: right, but sergiusens did a dput before that, and with a version that's higher than the one you did
[02:25] <rsalveti> which was migrated just fine for release
[02:25] <rsalveti> but then the now older version is stuck in proposed
[02:25] <robru> rsalveti: yeah, that's why my version got stuck in proposed, because it was too low to get through to release ;-)
[02:26] <robru> rsalveti: the next silo to publish it should safely overwrite the one in proposed and then also migrate to release just fine if the new version is higher.
[02:26] <rsalveti> robru: right, but I believe the right thing here is lp refusing your upload
[02:26] <rsalveti> you can't upload something that is older
[02:26] <robru> rsalveti: but why would it refuse an upload to proposed if the package wasn't in proposed?
[02:26] <rsalveti> robru: because there was a newer one in release :-)
[02:27] <rsalveti> guess a package copy directly into -proposed made that happen
[02:27] <robru> rsalveti: but does it check that? wouldn't it just say 'oh this package doesn't exist in proposed, i'll accept it'
[02:27] <rsalveti> robru: not with dput
[02:27] <rsalveti> at least afaik
[02:27] <robru> rsalveti: the train doesn't use dput, it uses copyPackage
[02:28] <rsalveti> robru: that's what I'm saying :-)
[02:28] <rsalveti> I think dput would cover that, but as the train is doing a package copy, that check might not necessarily happen
[02:29] <robru> rsalveti: either way, proposed did it's job by holding it there! ;-)
[02:29] <robru> alright I gotta run, back in a couple hours.
[02:29] <rsalveti> right, still something to check
[02:30] <rsalveti> the main problem though is that it got published without testing as 'done'
[02:30] <rsalveti> sergiusens: so just force and let's see how it goes :-)
[02:31] <sergiusens> rsalveti: I bet the changelog would look ugly :-P
[02:31] <rsalveti> right :-)
[02:36]  * rsalveti another dist-upgrade & reboot
[03:26] <infinity> rsalveti: Well done (re: goget-u-t going back in time)
[03:27] <rsalveti> yeah, first time I saw that :-)
[09:18] <seb128> hum
[09:18] <seb128> is there something wrong with the CI setup?
[09:18] <seb128> e.g on https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/382/console
[09:37] <seb128> fginther, ^?
[09:53] <jibel> ogra_, is it the right version of cgmanager in silo 3?
[09:55] <ogra_> jibel, yep, i just set it to testing done
[09:55] <ogra_> ah, cool
[10:49] <tsdgeos> fginther: any idea what's wrong in https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/386/console ?
[10:49] <tsdgeos> cihelp ↑
[10:52] <Ursinha> tsdgeos: hmm, I'll have a look
[10:53] <vila> tsdgeos: plars / psivaa_ may know better, there are some connectivity issues being worked on AFAIK
[10:54] <psivaa_> tsdgeos: vila: Ursinha: this is an issue with the wifi network in the lab, it was *thought to be fixed yesterday but we still see the issue
[10:55] <psivaa_> i've reported it back to the IS to have a look, we probably need to wait for them to fix it
[10:55] <Ursinha> psivaa_: thanks for the information
[10:57] <vila> psivaa_: thanks, well done
[10:57] <ev> psivaa_: are you able to get into a device and confirm it cannot connect to the wifi network?
[10:58] <psivaa_> ev: yes, i was able to login and connection from the device to the wifi appears working but can not go outside.
[10:58]  * ev nods
[11:07] <ogra_> cgmanager is in ... i'm starting an image build for rtm
[11:08] <seb128> ogra_, are we resuming landings for ota? ;-)
[11:08] <ogra_> seb128, yes, after this image has built we will start landing the already signed off silos that have ota-1 bugs
[11:08] <seb128> ogra_, great ;-)
[11:08] <ogra_> (and QA is actively testing the others)
[11:09] <ogra_> i'll also resume the nightly cron jobs ...
[11:09]  * seb128 is looking forward seeing fixes landing again ;-)
[11:09] <imgbot> [11:10] <seb128> wooot
[11:13] <Mirv> an image!
[11:14] <ogra_> not yet, not yet :)
[11:32] <brendand> pstolowski, marcustomlinson - either of you there?
[11:33] <pstolowski> brendand, hey
[11:33] <brendand> pstolowski, rtm silo 006
[11:33] <brendand> pstolowski, it mentions 3 bugs in the description but only one in the changelog
[11:36] <alf__> cihelp: Hi! The last few Mir CI runs are failing, see https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/3622/console . Any ideas?
[11:36] <alf__> alan_g: ^^
[11:37] <psivaa_> alf__: i think this was due to a wifi issue in the lab
[11:37] <psivaa_> let me take a look anyway
[11:38] <psivaa_> alf__: alan_g: yea, the wifi network in the lab is broken at the, we have a ticket open with the IS for this, will follow it up with them
[11:39] <alf__> psivaa_: Thanks. Note that this is a new problem, it started this morning. The jobs were working fine yesterday (after the last lab issue was fixed).
[11:39] <pstolowski> brendand, is it ok if I just update the changelog for this rtm version 0.6.8? in vivid we already have 0.6.9
[11:40] <pstolowski> brendand, (in other words, the changlog in vivd would not list these bugs)
[11:46] <psivaa_> alf__: ok, if that's the case the issue has reappeared again.
[12:12] <oSoMoN> trainguards: can silo 6 be published, please?
[12:13] <oSoMoN> trainguards: would anyone know why webbrowser-app fails to build in RTM silo 11? It seems the source package never reaches the PPA: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-011-1-build/67/console
[12:14] <Mirv> oSoMoN: ok
[12:17] <Mirv> oSoMoN: hmm. I don't see anything wrong in the output or a reason why the PPA would reject the upload. let's point that log https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-011-1-build/67/console to robru.
[12:19] <cjwatson> 2014-12-02 09:50:17 DEBUG   PPA exceeded its size limit (2071.00 of 2048.00 MiB). Ask a question in https://answers.launchpad.net/soyuz/ if you need more space.
[12:20] <cjwatson> Mirv,oSoMoN,robru: I've bumped that PPA's quota.  Please retry the job.
[12:20] <ogra_> building vivid too now ...
[12:21] <cjwatson> Though I'm a little confused as to why it shows as 2GiB used and 0 packages published.  Maybe needs GC ...
[12:22] <Mirv> cjwatson: oh, well spotted, thanks! it didn't occur to me to look at that figure given the PPA was "empty"
[12:24] <imgbot> [12:24] <imgbot> [12:25] <ogra_> damn
[12:25] <Mirv> "doesn't sound good"
[12:25] <Mirv> no package changes :(
[12:25] <ogra_> no no ... there were package channges
[12:26] <ogra_> the script got mad because cdimage flushed all old builds (and manifests) so there is nothing to compare against
[12:26] <ogra_> :(
[12:26] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09/daily-preinstalled/
[12:26] <ogra_> cgmanager	0.32-4ubuntu2rtm1 is in the manifest
[12:28] <cjwatson> It's not meant to do that ...
[12:28] <oSoMoN> cjwatson, thanks!
[12:28] <pstolowski> Mirv, hey, can you advice what to do about what I asked brendand earlier? here is the backlog http://pastebin.ubuntu.com/9344148/
[12:29] <cjwatson> The manifest's on LP, so still technically accessible, but that's annoying
[12:29] <ogra_> cjwatson, the last build was over a week ago ...
[12:29] <ogra_> iirc we only keep 1 week currently
[12:30] <cjwatson> Ah, yeah
[12:32] <Mirv> pstolowski: so you're asking if it's ok if you edit the rtm's 0.6.8 branch's changelog by hand? I guess so, although I wonder why it already isn't what it says at https://code.launchpad.net/~unity-team/unity-scopes-api/staging-rtm/+merge/242050 since it should pick the changelog entires from that commit message.
[12:35] <pstolowski> Mirv, yes, i'm asking if I can edit by hand and if it's ok that the changlog for same version in vivid stays as is.
[12:36] <Mirv> pstolowski: right, sure they can differentiate since the rtm branch is separate anyhow and the rtm build has the ~rtm in the version number
[12:36] <cjwatson> Something is odd.  ~ci-train-ppa-service/ubuntu-rtm/landing-011 has a bunch of packages with status Deleted, a scheduled deletion date set, but dateremoved None and they're still on disk, e.g. https://api.launchpad.net/devel/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-011/+sourcepub/4381101
[12:37] <cjwatson> I thought death-row ran on PPAs at some point ...
[12:37]  * cjwatson attempts to educate himself further from the code
[12:39] <cjwatson> 2014-12-02 07:59:04 INFO    Processing http://ppa.launchpad.net/ci-train-ppa-service/landing-011/ubuntu
[12:39] <cjwatson> 2014-12-02 07:59:04 INFO    Removing 0 files marked for reaping
[12:39] <cjwatson> 2014-12-02 07:59:04 INFO    Total bytes freed: 0
[12:39] <ogra_> 170 changelog fixed ...
[12:41]  * cjwatson pokes about on dogfood
[12:48] <ogra_> Mirv, ^^ if you like to ... land whats signed off by QA
[12:48] <cjwatson> Ah!  Nothing ever runs death-row on derived distributions.
[12:50] <Mirv> ogra_: \o/
[12:50]  * Mirv updates the spreadsheet too
[12:58] <cjwatson> I'm looking into the PPA quota issue, though it's no longer best handled on this channel.
[12:59] <cjwatson> oSoMoN: thanks for alerting me to what turned out to be a broader issue
[13:02] <Mirv> davmor2: is QA still happy with rtm-015? (for ota-1). just checking since it very barely missed the original topblocker deadline and has been sitting in the PPA for 3 weeks.
[13:07] <oSoMoN> cjwatson, glad that turned out to be helpful
[13:08] <davmor2> Mirv: talk to rvr and jibel, and see if it is in the list of silos to test :)
[13:08] <oSoMoN> trainguards: can I have a silo for line 55, please?
[13:09] <Mirv> davmor2: rvr: jibel: rtm-015 already QA signed off, it was just weeks ago. I guess I hesitate because the bug is not specifically retargeted to ota-1, and I'm unsure if it's automatically ok to land previous topblocker fixes now to ota-1.
[13:12] <rvr> Mirv: I don't know yet which silos are ok to land, but if it was tested weeks ago, then it's out of date. Silo needs to be retested with latest image.
[13:15] <Mirv> rvr: hmmkay. could you then maybe set up the rtm-015 for retesting if that's the way to go? not that of course much was landed during the last three weeks.
[13:49] <imgbot> [13:49] <imgbot> [13:49] <davmor2> \o/
[13:50] <popey> woah
[13:52] <pstolowski> Mirv, hey, so I've pushed updated changelog, but it refuses to rebuild it? ^
[13:52] <Mirv> pstolowski: try the force option
[13:54] <pstolowski> Mirv, that didn't help
[14:00] <Mirv> pstolowski: oh right, it's unintuitive. I kicked it too, now it seems do be continuing.
[14:00] <Mirv> pstolowski: you generally need to specify the package name in there. if the MP is updated, there is not even need for the force option.
[14:00] <rsalveti> wow, many updates
[14:00] <pstolowski> Mirv, ah, ok, thanks!
[14:01] <rsalveti> ogra_: what is the current vivid top most blocker?
[14:01] <rsalveti> sence the seeds got reverted
[14:03] <rsalveti> hm, no sound indicator with 39
[14:03] <rsalveti> let me update to 40
[14:04] <rsalveti> might be that other bug that happens after wizard
[14:08] <ogra_> rsalveti, there is no top blocker in vivid ... its vivid :P
[14:08] <ogra_> i dont think anyone even tracks "blockers" there
[14:49] <alexabreu> trainguards could you republish silo 005?
[15:05] <pstolowski> brendand, hey, silo rtm 6 has been rebuilt with updated changelog
[15:06] <brendand> pstolowski, ok
[15:09] <rsalveti> ogra_: thought sil was tracking that :-)
[15:10] <ogra_> not anymore i think ... all focus was shifted to rtm ... but i might be wrong ... ask him once he is not sick anymore :)
[15:14] <mterry> robru, hey man, if I have a silo
[15:14] <mterry> whoops
[15:15] <mterry> robru, if I have a silo and it wants an associated seed change, do we still just manually upload the seed change and hope everything lands around the same time?
[15:27] <Saviq> trainguards ↑ please
[15:29] <ogra_> mterry, yes
[15:30] <ogra_> (and no, we dont operate based on "hope" :) ... we can disable image builds til both is in the archive if needed)
[15:30] <seb128> bah
[15:30] <ogra_> woudl you prefer hope ?
[15:31] <seb128> rtm 169, my phone is ringing an alarm reminder but unity8 is not responding
[15:31] <seb128> can't stop the ringing
[15:31] <ogra_> use a hammer
[15:31] <ogra_> should not take more than five hits to quieten it ... else it's a bug
[15:31] <ogra_> :P
[15:31] <seb128> oh, ubuntu logo
[15:31] <seb128> sound stopped
[15:32] <seb128> but phone keeps vibrating
[15:32] <seb128> interesting :p
[15:32] <seb128> unity8 segfault I guess
[15:32] <ogra_> yeah
[15:32] <ogra_> you should have some nice .crash files
[15:32] <seb128> bah, back to a working phone
[15:32] <seb128> with vibrating in endless loop mode
[15:33] <ogra_> we had good bunch of scoperunner crashes recently ... that can tear down unity8 along it seems
[15:33] <ogra_> *a good bunch
[15:34]  * seb128 reboots
[15:34] <seb128> does anyone if the CI infra is known to have issues?
[15:34] <seb128> https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/393/console
[15:34] <seb128> seems the settings tests don't even run
[15:34] <seb128> the phablet-network setup fails
[15:34] <seb128> who should be pinged about that?
[15:37] <seb128> ogra_, Mirv, fginther, ^ somebody knows?
[15:37] <ogra_> seb128, IS
[15:37] <seb128> it's not the qa or ci teams?
[15:37] <ogra_> Ap issues ... started on the weekend
[15:37] <seb128> k, so it's not only settings?
[15:37] <ogra_> we have them in smoketesting too
[15:37] <seb128> is there a ticket/bug about it?
[15:37] <ogra_> seems to be the whole lab
[15:37] <ogra_> i think psivaa_ opened an RT
[15:38] <fginther> seb128, the problem is back again. Let me send out an email notice
[15:38] <seb128> fginther, thanks
[15:38] <seb128> is anyone working on resolving it?
[15:39] <fginther> seb128, yes, IS support has acknowledged the problem
[15:39] <psivaa_> seb128: https://rt.admin.canonical.com/Ticket/Display.html?id=77057 is the ticket,
[15:39] <seb128> psivaa_, thanks
[15:39] <psivaa_> fginther: thanks for sending out the email
[15:42] <seb128> ogra_, bah, unity8 apport file doesn't have a dump, no useful info of what happened then
[15:43] <ogra_> to bad
[15:43] <seb128> the media-hub-server crashed as well
[15:44] <ogra_> any scoperunner file ?
[15:44] <seb128> that as well
[15:44] <ogra_> yeah, i think i had the same issue here too then
[15:44] <ogra_> scoperunner, media-hub and unity8 crashing together
[15:45] <seb128> did you open a bug about it?
[15:45] <ogra_> nope, no data and i was on the road when it happened
[15:49] <oSoMoN> trainguards: can silo 6 be published, please?
[15:54] <seb128> ogra_, the media-hub-server bt seems to be code from /android/system/lib/libmedia_compat_layer.so
[15:54] <seb128> so no symbols
[15:55] <ogra_> yeah
[15:55] <ogra_> but you can at least add an oops pointer (grep it from whoopsie.log) to the bug
[15:55] <mterry> trainguards, may I please have a silo for spreadsheet line #57?
[16:01] <brendand> ogra_, i need to raise the topic of possibly being able to update apps in the store only for vivid
[16:02] <ogra_> raise it then :)
[16:02] <brendand> ogra_, consider it raised!
[16:03] <ogra_> :)
[16:03] <brendand> ogra_, so right now if i order an app to be updated to fix a test in vivid, then it will also update in RTM
[16:03] <brendand> ogra_, not such a big deal if it's test code only changed
[16:04] <brendand> ogra_, but if there are app changes since before the test code was updated, that also gets pulled in
[16:04] <brendand> ogra_, even worse if those are quite big changes
[16:05] <balloons> brendand, apart from getting support on the store side (which needs to happen), I suspect the simpliest way around this is to not pull from the store to build the image
[16:05] <brendand> balloons, yeah - that decision seems to be chewing on our posteriors at the moment
[16:06] <balloons> we have other reason we'd like to be able to push things to the store, but for now the differentiation seems to be based on the framework required
[16:06] <balloons> which may indeed make enough sense that more support on the store side for filtering uploads never materializes
[16:06] <john-mcaleely> rsalveti, do you know who's waiting for the rtm device tarball?
[16:06] <john-mcaleely> (it's ready with test results, etc)
[16:08] <rsalveti> john-mcaleely: mostly me atm :-)
[16:09] <rsalveti> john-mcaleely: still stuck in the bq's screen though
[16:09] <rsalveti> wonder wtf is happening here
[16:09] <rsalveti> oh, there you go
[16:09] <rsalveti> ubuntu logo
[16:10] <john-mcaleely> it looks good for me on #170
[16:32] <ogra_> balloons, brendand, the proper solution is to simply judge all core apps as rtm
[16:46] <brendand> ogra_, anything that stops us from freely developing apps on a *development* release is not a proper solution
[16:47] <brendand> ogra_, there's absolutely no reason to treat core apps differently from any other part of the system
[16:47] <ogra_> brendand, well, then we need a devel-store
[16:47] <ogra_> official store should be for rtm
[16:48] <ogra_> we have the ability to sideload clicks for developers ... i dont see why in-development core-apps need to go to the store
[16:48] <brendand> ogra_, well what about the image?
[16:49] <brendand> ogra_, that's really the issue
[16:49] <ogra_> (especially since they are most likely developed against a framework we do not even ship yet)
[16:49] <ogra_> brendand, rtm is the measure ...
[16:49] <ogra_> sil2100, !
[16:49] <ogra_> alive !!!
[16:50] <brendand> ogra_, let's think about the end goal here - i want to be able to update e.g. reminders or weather app in order to fix test failures in vivid, without impacting on RTM
[16:50] <ogra_> brendand, well, you cant ... the official store should be tied to the official release which is rtm
[16:51] <ogra_> if there is a way to have a devel store where the devel release can build from we should use that ...
[16:51] <brendand> ogra_, i can't isn't really good enough. there has to be a way
[16:51] <brendand> ogra_, or don't have the devel release pull from the store at all
[16:51] <ogra_> then there needs to be made a way ... there isnt one today
[16:51] <sil2100> ugh!
[16:51] <ogra_> and i dont think we can decouple the official store from rtm
[16:52] <brendand> ogra_, okay that's two different things - 'can't' and 'can't right now'
[16:53] <ogra_> well, i doubt we can do it in the vivid release timeframe
[16:53] <ogra_> (setting up a second store that is)
[16:53] <sil2100> New core app version needed for vivid?
[16:53] <brendand> ogra_, well no, but that's not the only way right?
[16:54] <ogra_> the only fasable one i see
[16:54] <ogra_> *feasable
[16:56] <brendand> ogra_, so the core-apps developers are doomed to not land anything for the next 6 months that is not eligible for RTM?
[16:57] <ogra_> brendand, well, why would they push anything to the store that you cant install (due to unsupported frameworks)
[16:57] <brendand> ogra_, i didn't suggest they should
[16:58] <ogra_> they should be able to provide clicks for testing etc ... and we should consider having a test-store but as i said, the official store needs to be tied to rtm
[16:58] <ogra_> and setting up a devel store wont be a small task i guess
[16:59] <ogra_> which is why i said above that i dont belive it is doable in vivid timeframe
[17:01] <sil2100> ogra_: if you could lead the meeting today one last time I would be grateful ;) I'll take care of the e-mail once I get all the updates I need
[17:01] <ogra_> sil2100, no prob, nothing to discuss anyway
[17:01] <ogra_> we re-started cron builds and had an image with cgmanager today ...
[17:02] <ogra_> the lab has still wifi issues so we dont get proper results yet
[17:03] <ogra_> plars, meeting ?
[17:03] <plars> ogra_: on the way
[17:15] <ahayzen> brendand, we with the music-app are bracing ourselves for this exact issue when vivid has an updated media-hub/mediascanner that we cannot then support in rtm :/
[17:16] <brendand> pete-woods, thostr_ - silo 007 is *7000* lines of diff....
[17:17] <brendand> woah
[17:17] <ogra_> tiny
[17:17] <sil2100> brendand: only 7k? Come on
[17:17] <brendand> pete-woods, thostr_ - okay 6200 actually - slight exaggeration for effect :P
[17:17] <sil2100> Isolated bugfix, land it!
[17:18] <brendand> seems to remove some tests too
[17:18] <brendand> this is using citrain-diff too so i'm sure it's not launchpad mischief
[17:19] <brendand> well i'll test it a bit anyway, but i'm somewhat uncomfortable with how big that diff is. and supposedly it's only fixing one bug
[17:19] <brendand> which by the looks of it is 'unity-scope-mediascanner needz moar codez!!!!'
[17:19] <thostr_> brendand: that's interesting
[17:20] <thostr_> brendand: as the single MPs alltogether are just 1500 loc
[17:21] <brendand> thostr_, unity-scope-mediascanner_0.2%2B15.04.20141110%7Ertm-0ubuntu1.dsc vs unity-scope-mediascanner_0.2%2B15.04.20141117.1%7Ertm-0ubuntu1.dsc
[17:23] <brendand> thostr_, doesn't show grooveshark results
[17:23] <brendand> thostr_, was that intended
[17:24] <thostr_> it should only add stuff
[17:24] <brendand> thostr_, it shows vimeo in settings but no results for it
[17:24] <brendand> thostr_, i just see youtube features
[17:25] <brendand> thostr_, think of something fast or i'll have to fail this silo :P
[17:25] <thostr_> what do you mean by vimeo in settings?
[17:26] <thostr_> do you have vimeo scope installed?
[17:27] <thostr_> brendand: but if you have grooveshark and vimeo scope installed it'll just show those
[17:29] <brendand> thostr_, no i don't have vimeo installed
[17:29] <brendand> thostr_, i do have grooveshark though
[17:29] <brendand> thostr_, and it doesn't show in Music scope anymore
[17:30] <thostr_> brendand: is it checked in the settings?
[17:30] <brendand> thostr_, i have 7digital, Songkick and Youtube
[17:30] <brendand> thostr_, yes also SoundCloud - which again isn't in the scope
[17:31] <brendand> thostr_, although like vimeo i don't have that scope
[17:31] <thostr_> brendand:  so which ones have you installed and which ones are checked in settings?
[17:31] <brendand> thostr_, everything is still checked in settings
[17:31] <brendand> thostr_, i haven't unchecked anything
[17:31] <thostr_> brendand: there is still an issue around settings showing scopes that are not installed, but htat is something we'll fix very shortly
[17:32] <thostr_> brendand: and grooveshark scope is still working on it's own?
[17:33] <brendand> thostr_, yes
[17:35] <brendand> thostr_, ftr once i install vimeo and soundcloud they are fine
[17:35] <brendand> thostr_, grooveshark still doesn't show up
[17:36] <thostr_> brendand: is grooveshark the newest version?
[17:36] <brendand> thostr_, it should be this is the latest rtm-proposed image
[17:37] <thostr_> brendand: that is strange, especially since no code around grooveshark aggregation was changed
[17:37] <thostr_> brendand: we'll investigate... can you put this on ice for time being
[17:37] <brendand> thostr_, well given the 6200 line diff maybe some code has been changed that you didn't think would be
[17:38] <thostr_> brendand: that might be... investigation is first where this big diff comes from
[17:38] <thostr_> brendand: it should really be only a fraction of this
[17:38] <brendand> thostr_, ok i need to have dinner anyway
[17:38] <brendand> thostr_, thanks
[17:38] <thostr_> brendand: how can I see the diff you're seeing?
[17:39] <brendand> thostr_, i put it here - http://people.canonical.com/~brendan-donegan/landing-007.diff
[17:39] <thostr_> brendand: thanks
[17:48] <mterry> Mirv, for spreadsheet line 57, is your comment why it hasn't gotten a silo yet?  I still wouldn't mind a silo to prep for landing in the meantime...  Unless we're short
[17:59] <robru> mterry: yeah unity8 is migrating, best to wait for that to finish before assiging a silo, otherwise you just have to rebuild right away anyway.
[18:15] <davmor2> ogra_, awe_: so image 39 mako vivid mms is working with my contract sim in both directions,  I think it might be the new udev at fault maybe?
[18:16] <davmor2> now I need food
[18:16] <ogra_> davmor2, or apparmor, did you check for denials ?
[18:20] <davmor2> ogra_: no damn it I'll have a look again tomorrow I just want to get 39 passed on 5 devices at 1 hour per device :P
[18:21] <ogra_> yeah
[18:21] <ogra_> take your time
[18:33] <robru> mterry: lol, tried to assign your silo. need the MP though, not the branch.
[18:36] <mterry> robru, kenvandine just told me that he's waiting on a ubuntu-system-settings rtm-backport branch to land, before he wants to land my silo so maybe hold off after all
[18:36] <mterry> robru, but I will fix that MP
[18:36] <robru> mterry: ok no worries
[18:37] <mterry> robru, also this silo would need an associated seed change -- do we still just make those in parallel or do we have a way of tying them together with the silo?
[18:37] <kenvandine> mterry, well i have a pile of backport branches, at least one of them touches the wizard
[18:37] <kenvandine> i'm going through the bugs now trying to prioritize them for ota-1 landing
[18:37] <robru> mterry: I'm not very familiar with seed changes, talk to ogra_ for that
[18:38] <robru> kenvandine: oh if you land anything today please let me hit publish on it, I need to test something ;-)
[18:38] <mterry> kenvandine, wait, how would that affect me landing drop-wizard in vivid?
[18:38] <kenvandine> robru, it won't be today :)
[18:39] <robru> darn! ;-)
[18:39] <kenvandine> mterry, because i want to make sure we have cherry-picked everything
[18:39] <kenvandine> just to be safe
[18:39] <kenvandine> mterry, i know something later than what i cherry-pick should be fine
[18:40] <kenvandine> mterry, well, i guess dropping the wizard will ensure we don't have any more wizard fixes :)
[18:40] <mterry> heh
[18:41] <kenvandine> and if there are issues, we can just fix them in the rtm branch
[18:42] <mterry> ogra_, do you know how we handle seed changes that are associated with a silo?  Just make them in parallel around the same time?
[18:42] <kenvandine> mterry, ok... i've convinced me... do you have a silo request already?
[18:42] <kenvandine> you could just add your uss branch to it
[18:42] <kenvandine> s/i've/you've/
[18:43] <mterry> kenvandine, yeah I have, line 57 of the spreadsheet
[18:43] <kenvandine> ok, add your uss branch there
[18:43] <kenvandine> it'll be easier to test in the silo anyway
[18:52] <mterry> robru, OK if you want to make a silo for line 57 now, I'd be obliged
[18:52] <mterry> robru, sorry for turnaround  :)
[18:53] <robru> mterry: no worries. do you think you'll publish it today?
[18:53] <robru> mterry: vivid 3
[18:53] <mterry> robru, um...  depends on if Cimi presses the approve button on my tests branch in short order.  So probably no
[18:54] <robru> mterry: darn it! I went my entire shift yesterday without a single publication. I have experimental train changes I need to make, but the last thing I want to do is land them and then go to sleep and let the europeans discover all the fun regressions. I need a real live publish I can test it on myself while I'm awake.
[18:55] <mterry> robru, :)
[18:55] <robru> mterry: I think it's a conspiracy... nobody wants to be my guinea pig ;-)
[18:55] <mterry> robru, didn't we just publish a unity8 silo?
[18:56] <robru> mterry: that was before I woke up
[19:02] <dobey> cihelp: ping. who best to set up jenkins ci job for monitoring MPs and running the tests on them, for a new branch?
[19:04] <fginther> dobey, we can do that, what's the branch?
[19:05] <dobey> fginther: lp:unity-scope-click/rtm-14.09
[19:06] <fginther> dobey, ack
[19:07] <dobey> fginther: thanks
[19:07] <kenvandine> fginther, oh... i have some rtm branches i'd like to see CI run for :)
[19:08] <kenvandine> fginther, lp:content-hub/rtm-14.09  and lp:ubuntu-system-settings/rtm-14.09
[19:08] <fginther> kenvandine, got it
[19:23] <kenvandine> fginther, thx
[19:26] <fginther> dobey, kenvandine, I just realized that this request is a lot more involved then adding a few configuration entries. I'll have to get back to you on this after investigating a little
[19:26] <kenvandine> fginther, cool, thanks
[19:27] <kenvandine> not urgent, but it would be nice to have CI run on the backport MPs for rtm
[19:33] <dobey> fginther: ok, thanks
[19:41] <kenvandine> Chipaca, you have settings in rtm 14 silo for testing, are you done with that?
[19:41] <kenvandine> Chipaca, if so, mind freeing it?
[19:52] <Chipaca> kenvandine: i can think about it :-p
[19:53] <Chipaca> kenvandine: i am done with that, in fact the tests went so well we decided to land it and have landed it. weeks ago :( sorry i forgot about the silo
[20:10] <robru> bfiller: oooooh you wanna publish that today? publish publish publish
[20:14] <davmor2> ogra_, sil2100: image 39 is as wonderful as it was yesterday, my issue now is I am out of day, so I'll finish the others tomorrow but none of the issues plaguing 40 are present in 39
[20:19] <kenvandine> Chipaca, cool, thanks
[20:20] <bfiller> robru: testing now then will publish :)
[20:20] <kenvandine> bfiller, robru really wants to push a button for you :)
[20:25] <sil2100> davmor2: thanks!
[20:25] <sil2100> davmor2: I need to fix the commitlog-generating machines to see what landings got into #40
[20:25] <sil2100> davmor2: right now the openstack machine seems to be 'out of free space', but it seems I can't free any space myself
[20:26] <sil2100> So I'll take care of it tomorrow
[20:31] <robru> hm
[20:50] <robru> *phew*
[21:04] <robru> brb, lunch. nothing is allowed to explode until I get back.
[21:13] <kenvandine> robru, i'll find something to go boom
[21:35] <robru> kenvandine: nuh uh! I only deleted problems this time, I swear!
[21:48] <kenvandine> :)
[22:06] <robru> whooooooooooo
[22:08] <robru> mterry: https://ci-train.ubuntu.com/job/ubuntu-landing-007-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-keyboard_0.99.trunk.phablet2+15.04.20141202-0ubuntu1.diff any love for a packaging ack? looks like a nice python2->3 port.
[22:08]  * mterry looks
[22:12] <mterry> robru, what's the story with python:any in build-deps?  I know it's a multiarch thing, I'm just not sure why it's used for build-deps?   In the switch to python3, the :any is dropped
[22:12] <robru> mterry: not sure. barry? ^
[22:13] <barry> robru, mterry sorry, please ping doko in #ubuntu-devel (though he's probably eod)
[22:26] <robru> mterry: hm, no doko I guess. is there no documentation for this?
[22:26] <mterry> robru, oh right I forgot
[22:26] <mterry> robru, let me look real quick -- diff looks fine, I just thought it was a weird drop
[22:26] <robru> mterry: yeah I have no idea but presumably bfiller tested it in his silo and it was working.
[22:27] <bfiller> robru: silo 7? yes it's tested
[22:28] <robru> bfiller: any thoughts on the switch from 'python:any' to 'python3' (without the :any?)
[22:28] <mterry> robru, ok, it's because python is just an interpreter, and it doesn't matter which arch version you have installed
[22:28] <mterry> robru, so I think it's to enable crossbuilding
[22:29] <bfiller> robru: not sure, Elleo made that change to support python3 autopilot tests
[22:29] <robru> mterry: should that not get kept then?
[22:29] <mterry> robru, so looks like this diff will make crossbuilding harder.  Which isn't good, but I don't *think* it's a blocker, just an annoyance
[22:29] <robru> mterry: fair. so you approve?
[22:30] <mterry> robru, sure...  but Elleo ^
[22:32] <robru> alright, moment of truth... will the package make it to proposed ;-)
[22:34] <Elleo> mterry: would it be better to set that as python3:any?
[22:34] <Elleo> debian packaging isn't my strong suit, so am more than happy to be corrected :)
[22:35] <mterry> Elleo, I think so.  I don't quite understand all the requirements of cross-building, but I believe that helps with doing that.  It was python:any before you changed it to python3, so I suspect it should be python3:any.  But no big deal
[22:35] <mterry> Elleo, i.e. not urgent.  Just next time you touch the packaging, maybe make that edit
[22:36] <Elleo> mterry: I could add it to the MR now if it's not going to cause issues with the building, landing, etc.?
[22:37] <robru> sweeeet
[22:37] <Elleo> maybe simplest to just make a new MR for that change
[22:37]  * mterry shrugs
[22:37] <robru> Elleo: oh yeah no, way too late to make that change. you'd have to rebuild and retest and it would be a waste of bfiller's whole afternoon.
[22:38] <Elleo> robru: okay
[22:38] <robru> Elleo: next time you have a branch for ubuntu-keyboard just sneak that in with it ;-)
[22:38] <Elleo> heh
[22:38] <bfiller> Elleo, robru : it's fine with me if you want to update the MR. I don't mind retesting it
[22:38] <robru> bfiller: no it's published already ;-)
[22:39] <bfiller> oh, in that case, rock on :)
[22:40] <Elleo> bfiller: I'll be making a new branch for some extra autopilot tests soon, so I'll just fix it in that one
[22:40] <bfiller> Elleo: ack
[23:01] <sergiusens> mterry: Elleo it's sort of explained here: https://wiki.debian.org/Multiarch/HOWTO
[23:03] <Elleo> sergiusens: thanks
[23:10]  * mterry never deals with crossbuilding
[23:14] <robru> mterry: yeah I prefer happybuilding.
[23:14] <mterry> :p
[23:16] <mterry> charles, testing fix now
[23:18] <charles> mterry, the brightness slider and settings menuitems seem to do the Right Thing in the greeter, which is nice
[23:19] <mterry> charles, huh, I get nothing...
[23:19] <mterry> maybe I typo'd
[23:19] <mterry> charles, I flashed latest vivid, installed my branch, then made your change
[23:19] <mterry> charles, anything else I need?
[23:19] <charles> mterry, make sure you have r274 instead of r273, I had a typo a couple of minutes ago
[23:20] <charles> I'm buildding a test deb with r274 now
[23:20] <mterry> charles, ah!
[23:20] <mterry> charles, I wondered why there would be a phone_greeter profile just sitting there unused  :)
[23:20] <charles> ya... :)
[23:21] <charles> I thought about adding one, but there's nothing in the phone menu that makes sense to remove in the greeter
[23:21] <charles> so it's perfect as-is
[23:22] <charles> (mterry, ordinarilly I would test from a builddeb before pinging, but I wanted to catch you before you EODed :)
[23:22] <mterry> charles, yeah thanks  :)
[23:23] <mterry> charles, works for me
[23:23] <charles> mterry, same here
[23:24] <mterry> charles, do we still do https://wiki.ubuntu.com/Process/Merges/Checklists/indicator-power ?
[23:24] <mterry> because I notice you haven't....  ;)
[23:25] <charles> well, let's do this properly
[23:25] <mterry> charles, I mean I don't care
[23:25] <mterry> charles, just didn't know if I should fill it out when I add my approve comment
[23:27] <charles> mterry, IMO it's not a big deal for this one
[23:27] <mterry> sure
[23:27] <mterry> charles, approved
[23:27] <charles> mterry, thanks
[23:28] <charles> mterry, do you want to handle siloing in with your unity8 greeter changes?
[23:30] <charles> mterry, since your changes are blocked on this
[23:31] <mterry> charles, don't block on me yet, I'm going to have design look at everything together and OK landing the unity8 side that enables all this
[23:31] <mterry> charles, but yeah i won't land mine without including yours, if yours doesn't land first


[00:04] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_messagelib build #192: STILL FAILING in 57 min: https://kci.pangea.pub/job/bionic_unstable_messagelib/192/
[00:36] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_amarok build #99: STILL UNSTABLE in 53 min: https://kci.pangea.pub/job/bionic_unstable_amarok/99/
[00:36] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_cantor build #94: STILL UNSTABLE in 53 min: https://kci.pangea.pub/job/bionic_unstable_cantor/94/
[00:37] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kstars build #127: STILL UNSTABLE in 1 hr 28 min: https://kci.pangea.pub/job/bionic_unstable_kstars/127/
[00:57] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:57] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_akonadiconsole build #91: FIXED in 52 min: https://kci.pangea.pub/job/bionic_unstable_akonadiconsole/91/
[01:37] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kmailtransport build #111: STILL FAILING in 3 min 43 sec: https://kci.pangea.pub/job/bionic_unstable_kmailtransport/111/
[02:31] -queuebot:#kubuntu-devel- Builds: Kubuntu Desktop amd64 [Bionic Final] has been updated (20180424)
[02:32] -queuebot:#kubuntu-devel- Builds: Kubuntu Desktop i386 [Bionic Final] has been updated (20180424)
[03:10] <valorie> \o/
[03:11] <valorie> test, test, test
[03:11] <valorie> just sent the call to the lists
[03:13] <valorie> http://iso.qa.ubuntu.com/qatracker/milestones/389/builds for those who don't have the link memorized
 @DarinMiller, Latest nvidia-prime fix the SDDM login issue and fixes the funcky krunner and plasma corruption. Excellent!
 Also, the NVidia driver behaves much better on the hybrid laptop.  18.04 was showing a 5% framerate loss in glxgears and window movement was jittery.  Not any more!
[03:29] <valorie> from the new ISO, @DarinMiller ?
 daily updates with proposed enabled....
[03:30] <valorie> ah
[03:30] <valorie> would be good to know that the fix made it to the ISO
[03:34]  * valorie writes to the usb drive
 zsync'ing now...
[03:51] <valorie> \o/
[05:21] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_messagelib build #113: FAILURE in 12 min: https://kci.pangea.pub/job/bionic_stable_messagelib/113/
 nvidia-prime is not on the iso, so will be in the repos to install straight away
 @DarinMiller, great :)
[06:27] <valorie> ah, of course
[06:28] <valorie> duh
[06:28] <acheronuk> I'm running out of bugs to put on the release notes!
[06:29] <acheronuk> I put some in known issues, then people damn well fix them!
[07:03] <valorie> I ran into my oem bug again
[07:03] <valorie> added a photo!
[07:04] <valorie> wth, i386 has 5/6 done
[07:04] <valorie> amd64 3/6
[07:04] <valorie> and I did 2 of 'em
[07:04] <acheronuk> shutdown bug?
[07:04] <valorie> yes
[07:05] <valorie> LP:1766056
[07:05] <valorie> huh
[07:05] <valorie> what do the bugbot need
[07:06] <acheronuk> a hash
[07:06] <acheronuk> LP: #1766056
[07:07] <acheronuk> though I think Americans call # something else
[07:08] <acheronuk> I have a feeling that microcode errata message has nothing to do with it, and is not fatal.
[07:10] <valorie> no, not faral
[07:10] <valorie> fatal
[07:10] <acheronuk> hmmmm.... dunno actually
[07:10] <valorie> once I shut down with the power button, no more issues
[07:11] <valorie> well, driver manager used to report microcode, and it no longer does
[07:11] <acheronuk> well, fatal as in that it causes a reboot hang
[07:11] <valorie> so I don't know if I need an update or not
[07:11] <valorie> well, it does
[07:12] <acheronuk> I meant that message might be coincidental, but I am not sure. seems a bit more several than the similar one I frequently see on some hardware and has no ill effect
[07:12] <acheronuk> s/several/severe
[07:12]  * acheronuk shrugs
[07:14] <acheronuk> I'll add to the notes anyway :)
[07:17] <acheronuk> valorie: regards microcode: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.5
[07:19] <valorie> well, last I tried it worked for the other drivers
[07:19] <valorie> just no longer displayed anything about microcode
[07:20] <valorie> I tried fwupdate --enable but it says it can't be done on this machine with this tool
[07:21] <valorie> no clue what to use to check
[07:27] <valorie> off irc after a very long day
[08:35] -kubuntu-ci:#kubuntu-devel- Project merger_latte-dock build #290: FAILURE in 4.7 sec: https://kci.pangea.pub/job/merger_latte-dock/290/
[08:38] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[08:38] -kubuntu-ci:#kubuntu-devel- Project merger_latte-dock build #291: FIXED in 11 sec: https://kci.pangea.pub/job/merger_latte-dock/291/
[09:41] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #2193: SUCCESS in 53 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/2193/
[09:42] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #2193: SUCCESS in 1 min 17 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/2193/
[09:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #2193: SUCCESS in 4 min 16 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/2193/
[10:41] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kstars build #658: STILL FAILING in 1 min 52 sec: https://kci.pangea.pub/job/xenial_unstable_kstars/658/
[10:43] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kstars build #276: STILL FAILING in 4 min 26 sec: https://kci.pangea.pub/job/artful_unstable_kstars/276/
[10:44] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kstars build #659: STILL FAILING in 1 min 48 sec: https://kci.pangea.pub/job/xenial_unstable_kstars/659/
[10:48] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kstars build #277: STILL FAILING in 4 min 24 sec: https://kci.pangea.pub/job/artful_unstable_kstars/277/
[11:08] <BluesKaj> Hi folks
[11:15] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kstars build #128: STILL UNSTABLE in 35 min: https://kci.pangea.pub/job/bionic_unstable_kstars/128/
[11:28] <mmazur^> Just upgraded to 18.04; org.kde.plasma.timer counts down time twice as fast (2 seconds per 1 second). Can someone confirm?
[11:40] <acheronuk> mmazur^: https://bugs.kde.org/show_bug.cgi?id=381173
[11:40] <acheronuk> mildly amazed KDE have done nothing on that!
[11:46] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kstars build #129: STILL UNSTABLE in 31 min: https://kci.pangea.pub/job/bionic_unstable_kstars/129/
[11:52] <mmazur^> Reported:2017-06-14, this is perfect :)
[12:08] <mmazur^> acheronuk, right, it's not maintained.
[12:08] <acheronuk> clearly not!
[12:13] <mmazur^> A bit unfortunate. I'd fix it if I had any clue of how those things are written, but I don't. No idea what the mechanism is for it getting the 'second has passed' signal.
[12:16] <acheronuk> mmazur^: is this on a real machine, or in a VM?
[12:19] <mmazur^> real
[12:19] <mmazur^> Ah, there's a tutorial for a qtquick 2.0 clock app.
[12:20] <mmazur^> Maybe that'll help.
[12:28] <mmazur^> Hmm, so seems some qt bug is causing the timer to trigger twice per second instead of once.
[12:39] <mmazur^> Wonder how hard it is to become a maintainer of a plasmoid.
[12:44] <acheronuk> really need to talk to people in #plasma
[13:00] <mparillo> kteatime appears to count down normally.
[13:03] <mmazur^> Ok, so the problem is the following. Either all of qml or just something specific to the timer plasmoid makes the Timer QML Type work badly and trigger two signals for every tick.
[13:04] <mmazur^> I can work around this inside the plasmoid by assuming qt is completely unreliable.
[13:04] <mmazur^> However, this sorta kinda feels like a maybe serious bug? Dunno what about that.
[13:07] <acheronuk> mparillo: kronometer stop watch counts up fine as well
[13:14] <mmazur^> Both are standalone cpp apps, and I'm having an issue with a qml plasmoid.
[13:15] <mmazur^> I see the timer type is used 63 times in various plasmoids and whatnot. Hopefully this does not cause issues in other places.
[14:15] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_libkgapi build #142: STILL FAILING in 2 min 42 sec: https://kci.pangea.pub/job/artful_unstable_libkgapi/142/
[14:16] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_libkgapi build #121: STILL FAILING in 4 min 13 sec: https://kci.pangea.pub/job/xenial_unstable_libkgapi/121/
[14:20] <mmazur^> Aaaand fixed, along with a few other issues.
[14:20] <mmazur^> Now the question is how to get it merged in the simplest manner.
[14:21] <acheronuk> https://community.kde.org/Get_Involved/development#Submitting_your_first_patch
 submit the fix upstream to KDE, then Kubnutu can cherry-pick that commit
 thanks for the fix, BTW!
[14:29] <mmazur^> acheronuk, do plasmoids have maintainers? Cause that's probably a better idea than to submit a patch to nobody.
 not that I am aware. you can submit it and request review by the plasma team
 yeah, just tag #plasma Plasma
 it'll get noticed, don't worry :)
 especially because there's a Plasma sprit underway right now
[14:36] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_libkgapi build #64: NOW UNSTABLE in 23 min: https://kci.pangea.pub/job/bionic_unstable_libkgapi/64/
[14:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #2194: SUCCESS in 51 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/2194/
[14:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #2194: SUCCESS in 1 min 17 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/2194/
[14:46] <mmazur^> Ok, thanks for the info. I'll take care of submitting the code some time today. And if anybody's interested in pursuing the underlying QT issue (which might affect other plasmoids), then a starting point is here: https://bugs.kde.org/show_bug.cgi?id=381173#c6
[14:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #2194: SUCCESS in 4 min 16 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/2194/
[15:15] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_kdepim-runtime build #136: STILL FAILING in 3 min 49 sec: https://kci.pangea.pub/job/xenial_stable_kdepim-runtime/136/
[15:15] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kdepim-runtime build #148: FAILURE in 3 min 56 sec: https://kci.pangea.pub/job/artful_stable_kdepim-runtime/148/
[15:17] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdepim-runtime build #399: STILL FAILING in 5 min 49 sec: https://kci.pangea.pub/job/xenial_unstable_kdepim-runtime/399/
[15:19] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kdepim-runtime build #267: FAILURE in 8 min 18 sec: https://kci.pangea.pub/job/artful_unstable_kdepim-runtime/267/
[15:25] -kubuntu-ci:#kubuntu-devel- Project xenial_stable_polkit-kde-agent-1 build #72: STILL FAILING in 2 min 42 sec: https://kci.pangea.pub/job/xenial_stable_polkit-kde-agent-1/72/
[15:26] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_polkit-kde-agent-1 build #490: STILL FAILING in 3 min 42 sec: https://kci.pangea.pub/job/xenial_unstable_polkit-kde-agent-1/490/
[15:44] -kubuntu-ci:#kubuntu-devel- Project artful_stable_polkit-kde-agent-1 build #95: UNSTABLE in 21 min: https://kci.pangea.pub/job/artful_stable_polkit-kde-agent-1/95/
[15:44] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_polkit-kde-agent-1 build #109: STILL UNSTABLE in 21 min: https://kci.pangea.pub/job/bionic_stable_polkit-kde-agent-1/109/
[15:46] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_polkit-kde-agent-1 build #209: FAILURE in 23 min: https://kci.pangea.pub/job/artful_unstable_polkit-kde-agent-1/209/
[15:46] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[15:46] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kdepim-runtime build #128: FIXED in 35 min: https://kci.pangea.pub/job/bionic_unstable_kdepim-runtime/128/
[15:46] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_polkit-kde-agent-1 build #83: FAILURE in 24 min: https://kci.pangea.pub/job/bionic_unstable_polkit-kde-agent-1/83/
[15:58] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_polkit-kde-agent-1 build #491: STILL FAILING in 6 min 40 sec: https://kci.pangea.pub/job/xenial_unstable_polkit-kde-agent-1/491/
[16:11] -kubuntu-ci:#kubuntu-devel- Project artful_stable_polkit-kde-agent-1 build #96: STILL UNSTABLE in 19 min: https://kci.pangea.pub/job/artful_stable_polkit-kde-agent-1/96/
[16:12] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[16:12] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_polkit-kde-agent-1 build #210: FIXED in 20 min: https://kci.pangea.pub/job/artful_unstable_polkit-kde-agent-1/210/
[16:12] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[16:12] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_polkit-kde-agent-1 build #84: FIXED in 20 min: https://kci.pangea.pub/job/bionic_unstable_polkit-kde-agent-1/84/
[16:25] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_polkit-kde-agent-1 build #110: STILL UNSTABLE in 33 min: https://kci.pangea.pub/job/bionic_stable_polkit-kde-agent-1/110/
[19:02] <valorie> aha, my installer bug isn't just me, and it isn't just kubuntu
[19:02] <valorie> https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1766049
[19:02] <valorie> actually I didn't file that one because I thought it was a one-off
 We definitely need to publish that as knonw issue on the release notes and how to do gentle restart if issue is encountered (http://blog.kember.net/articles/reisub-the-gentle-linux-restart/)
 good find though!
[21:55] <mparillo[m]> Good test just now of the live ISO on real HW. The previous spin was glitchy with the nouveau drivers. This seems to have no artifacts whatsoever on the same HW.
[22:44] <valorie> mparillo[m]: excellent!
[23:06] -kubuntu-ci:#kubuntu-devel- Project mgmt_merger build #1084: SUCCESS in 6 min 4 sec: https://kci.pangea.pub/job/mgmt_merger/1084/
[23:14] <valorie> @DarinMiller, good thought
[23:14] <valorie> did you see that, mparillo[m]?
[23:14] <valorie> since you are awesome with the wiki
[23:17] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ruqola build #191: STILL FAILING in 10 min: https://kci.pangea.pub/job/bionic_unstable_ruqola/191/
[23:19] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ktorrent build #117: STILL FAILING in 13 min: https://kci.pangea.pub/job/bionic_unstable_ktorrent/117/
[23:22] <mparillo> The magic sys request link?
[23:25] <valorie> right, under known issues
[23:25] <valorie> the BR# is right above that
[23:25] <valorie> I didn't even think to do REISUB
[23:25] <valorie> duh
[23:27] <acheronuk> only the oem one is on the wiki so far
[23:28] <valorie> I have a feeling both might be the same bug in the end
[23:29] <acheronuk> likely
[23:29] <mparillo> Funny thing: I have seen the shutdown not be so graceful, but not recently.
[23:43] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_polkit-kde-agent-1 build #111: STILL UNSTABLE in 35 min: https://kci.pangea.pub/job/bionic_stable_polkit-kde-agent-1/111/
[23:44] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kalzium build #84: STILL UNSTABLE in 35 min: https://kci.pangea.pub/job/bionic_stable_kalzium/84/
[23:45] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_messagelib build #114: STILL FAILING in 38 min: https://kci.pangea.pub/job/bionic_stable_messagelib/114/
[23:49] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ark build #131: STILL UNSTABLE in 40 min: https://kci.pangea.pub/job/bionic_unstable_ark/131/
[23:49] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_messagelib build #193: STILL FAILING in 42 min: https://kci.pangea.pub/job/bionic_unstable_messagelib/193/
[23:51] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_okular build #139: FAILURE in 45 sec: https://kci.pangea.pub/job/bionic_unstable_okular/139/


[17:07] <dobey> is there any way to have the launchpad builders configured to have apt output verbose messages on dependency failures? "is not going to be installed" is not a particularly useful error message in itself :-/
[18:36] <cjwatson> dobey: unfortunately not AFAIK
[18:36] <cjwatson> I think this should be fixed in apt itself personally
[18:36] <dobey> sure. i just didn't know if it had a way to do that already or not
[21:53] <mwhudson> is there any kind of planning for git-based recipe builds yet?
[22:00] <blr> mwhudson: not work we've moved on to yet, but would certainly appreciate any thoughts you might have on recipes.
[22:00] <mwhudson> blr: heh
[22:00] <mwhudson> blr: i want it, and a pony
[22:00] <mwhudson> no actual thought applied yet
[22:00] <blr> after the UI work I suspect that will be the next thing to tackle
[22:08] <mwhudson> blr: to be specific, i want to built tip-of-tree packages of go
[22:08] <mwhudson> but that's about all i really _want_ :)
[22:09] <mapreri> (and a pony)
[22:09] <blr> well, that certainly sounds reasonably - we'll sign you up for dogfooding it when we get on to it. Thanks for volunteering heh :)
[22:09] <blr> reasonable even.
[22:09] <mwhudson> i guess lp could assume the use of gbp, but i don't really understand gbp
[22:09] <mwhudson> (and i'm not sure anyone does, from what i hear)
[22:09] <mwhudson> mapreri: maybe the pony should be implied
[22:09]  * mapreri does understand gbp
[22:21] <mwhudson> mapreri: heh
[22:22] <mwhudson> well maybe you can help then
[22:22] <mwhudson> for the case where upstream is in git and you are building snapshots, it seems lots of what gbp does is not required
[23:17] <cjwatson> mwhudson: I'd sort of like to start by taking the existing recipe format and seeing what doesn't work
[23:17] <cjwatson> mwhudson: and hopefully the answer is not much
[23:18] <mwhudson> fair enough
[23:18] <cjwatson> I don't want to assume gbp because I'm a git-dpm partisan :-) but I think neither is directly relevant to recipes
[23:19] <cjwatson> doesn't really matter what the patch format is or whatever, we just need to merge or subtreeify something corresponding to the packaging
[23:34] <mwhudson> cjwatson: right, i guess git-dpm or gbp or whatever comes in more for maintaining the thing that gets merged or subtreeified
[23:34] <cjwatson> indeed


[17:01] <dsmythies> Is there a doc team meeting?
[17:09] <pmatulis_> dsmythies: i'm not sure
[17:14] <dsmythies> pmatulis_ : I guess not. Anway, we should do a point release of serverguide 14.04, then split out 14.04 and trunk. Then proceed with trunk as 16.04
[17:14] <pmatulis_> dsmythies: yes, we need to do that
[17:14] <dsmythies> I have been busy, but will try to get on it.
[17:27] <pmatulis_> dsmythies: you and me both. kids/family + work + house maintenance. it's nuts


[07:05] <saa> can someone help me
[07:06] <Guest9318> bymistake i was showing demo of installing linux
[07:06] <Guest9318> i went ahead with until login option and then cancelled the installation
[07:06] <Guest9318> now my data has gone
[07:06] <Guest9318> i took some help and that person tried to use testdisk
[07:07] <Guest9318> i can see now my partition but it shows error as "Error mounting /dev/sda8 at /media/lubuntu/03b3361d-c8f6-490b-9c52-45a7f734b0b3: Command-line `mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/sda8" "/media/lubuntu/03b3361d-c8f6-490b-9c52-45a7f734b0b3"' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/sda8,        missing codepage or helper program, or other error        In some
[07:07] <Guest9318> is there any way i can read/recover data from this drive
[07:07] <Guest9318> it is very important data i have
[07:07] <Guest9318> pl. help
[07:11] <Guest9318> is there anyone available to help
[07:13] <Guest9318> i need help
[07:13] <Guest9318> i by mistake went ahead till last command of linux installation and then cancelled
[07:13] <Guest9318> i have lot of important data
[07:14] <Guest9318> now i need to see whether i can recover data
[07:23] <Guest9318> i need help from someone to see if i can retrieve data from a drive
[07:23] <Guest9318> i have mounted it through livecd
[07:24] <Guest9318> can someone just guide me so that i can get confirmation whether i have any hope to recover data or nt
[10:19] <Zalmoxis> hello
[10:23] <Zalmoxis> if there is someone here to talk to, I am interested in helping regarding the artwork area
[11:38] <Zalmoxis> ding dong
[13:38] <Zalmoxis> this is pointless


[00:05] -queuebot:#ubuntu-release- New: rejected linux-restricted-modules-media-fixup [source] (jammy-proposed) [22.04.1]
[00:07] -queuebot:#ubuntu-release- New: rejected linux-restricted-modules-media-fixup [source] (focal-proposed) [20.04.1]
[02:09] -queuebot:#ubuntu-release- Builds: Edubuntu Desktop amd64 [Mantic Daily] has been updated (20230624)
[02:17] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Mantic Daily] has been updated (20230624)
[02:34] -queuebot:#ubuntu-release- Builds: Xubuntu Minimal amd64 [Mantic Daily] has been updated (20230624)
[03:02] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Mantic Daily] has been updated (20230624)
[05:08] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Mantic Daily] has been updated (20230624)
[05:08] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Mantic Daily] has been updated (20230624)
[05:57] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Mantic Daily] has been updated (20230624)
[05:57] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Mantic Daily] has been updated (20230624)
[05:57] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Mantic Daily] has been updated (20230624)
[05:57] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Mantic Daily] has been updated (20230624)
[05:57] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Mantic Daily] has been updated (20230624)
[05:57] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Mantic Daily] has been updated (20230624)
[06:33] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Mantic Daily] has been updated (20230624)
[06:33] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64 [Mantic Daily] has been updated (20230624)
[06:55] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Mantic Daily] has been updated (20230624)
[06:58] -queuebot:#ubuntu-release- Unapproved: debootstrap (kinetic-proposed/main) [1.0.127ubuntu1.2 => 1.0.127ubuntu1.3] (desktop-core)
[07:11] -queuebot:#ubuntu-release- Unapproved: debootstrap (lunar-proposed/main) [1.0.128+nmu2ubuntu1.1 => 1.0.128+nmu2ubuntu1.2] (desktop-core)
[07:15] -queuebot:#ubuntu-release- Unapproved: debootstrap (jammy-proposed/main) [1.0.126+nmu1ubuntu0.4 => 1.0.126+nmu1ubuntu0.5] (desktop-core)
[07:17] -queuebot:#ubuntu-release- Unapproved: debootstrap (focal-proposed/main) [1.0.118ubuntu1.10 => 1.0.118ubuntu1.11] (core)
[07:25] <mitya57> https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html was generated on 2023.06.23 13:11:34 +0000. Is britney broken?
[07:58] <vorlon> mitya57: thanks, was affected by the api.launchpad.net issue
[07:58] <vorlon> mitya57: the current run looks like it should finish successfully now that I've cleared the stale cache
[07:58] <mitya57> Thank you!
[08:10] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Mantic Daily] has been updated (20230624)
[08:43] -queuebot:#ubuntu-release- Builds: Ubuntu Core amd64 edge [Mantic Daily] has been updated (20230624)
[09:07] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop (Legacy) amd64 [Mantic Daily] has been updated (20230624)
[10:14] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Mantic Daily] has been updated (20230624)
[10:14] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Mantic Daily] has been updated (20230624)
[10:14] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Mantic Daily] has been updated (20230624)
[10:14] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Mantic Daily] has been updated (20230624)
[11:27] -queuebot:#ubuntu-release- New binary: ppx-cold [amd64] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:27] -queuebot:#ubuntu-release- New binary: python-flask-marshmallow [amd64] (mantic-proposed/universe) [0.15.0-2] (no packageset)
[11:27] -queuebot:#ubuntu-release- New binary: ppx-globalize [amd64] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: haskell-sdl2-image [amd64] (mantic-proposed/none) [<IP_ADDRESS>-2] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: ppx-enumerate [amd64] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: vfu [amd64] (mantic-proposed/universe) [5.09-2] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: haskell-sdl2-mixer [amd64] (mantic-proposed/none) [<IP_ADDRESS>-2] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: python-docformatter [amd64] (mantic-proposed/universe) [1.7.2-1] (no packageset)
[11:40] -queuebot:#ubuntu-release- New binary: vfu [arm64] (mantic-proposed/universe) [5.09-2] (no packageset)
[11:40] -queuebot:#ubuntu-release- New binary: vfu [ppc64el] (mantic-proposed/universe) [5.09-2] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: vfu [armhf] (mantic-proposed/universe) [5.09-2] (no packageset)
[11:42] -queuebot:#ubuntu-release- New binary: cvc5 [amd64] (mantic-proposed/universe) [1.0.5-3] (no packageset)
[11:42] -queuebot:#ubuntu-release- New binary: haskell-sdl2-mixer [ppc64el] (mantic-proposed/none) [<IP_ADDRESS>-2] (no packageset)
[11:43] -queuebot:#ubuntu-release- New binary: haskell-sdl2-image [ppc64el] (mantic-proposed/none) [<IP_ADDRESS>-2] (no packageset)
[11:43] -queuebot:#ubuntu-release- New binary: ppx-globalize [ppc64el] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:43] -queuebot:#ubuntu-release- New binary: optee-client [armhf] (mantic-proposed/universe) [3.20.0-1] (no packageset)
[11:43] -queuebot:#ubuntu-release- New binary: ppx-enumerate [ppc64el] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:43] -queuebot:#ubuntu-release- New binary: ppx-cold [armhf] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:44] -queuebot:#ubuntu-release- New binary: ppx-cold [ppc64el] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:44] -queuebot:#ubuntu-release- New binary: optee-client [arm64] (mantic-proposed/universe) [3.20.0-1] (no packageset)
[11:44] -queuebot:#ubuntu-release- New binary: ppx-globalize [armhf] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:45] -queuebot:#ubuntu-release- New binary: ppx-cold [arm64] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:45] -queuebot:#ubuntu-release- New binary: ppx-enumerate [armhf] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:45] -queuebot:#ubuntu-release- New binary: ppx-enumerate [arm64] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:45] -queuebot:#ubuntu-release- New binary: ppx-globalize [arm64] (mantic-proposed/none) [0.16.0-1] (no packageset)
[11:47] -queuebot:#ubuntu-release- New binary: haskell-sdl2-image [arm64] (mantic-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[11:50] -queuebot:#ubuntu-release- New binary: cvc5 [s390x] (mantic-proposed/universe) [1.0.5-3] (no packageset)
[11:51] -queuebot:#ubuntu-release- New binary: cvc5 [ppc64el] (mantic-proposed/universe) [1.0.5-3] (no packageset)
[11:52] -queuebot:#ubuntu-release- New binary: haskell-sdl2-mixer [arm64] (mantic-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[11:52] -queuebot:#ubuntu-release- New binary: vfu [s390x] (mantic-proposed/universe) [5.09-2] (no packageset)
[11:54] -queuebot:#ubuntu-release- New binary: haskell-sdl2-image [s390x] (mantic-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[11:55] -queuebot:#ubuntu-release- New binary: cvc5 [arm64] (mantic-proposed/universe) [1.0.5-3] (no packageset)
[11:55] -queuebot:#ubuntu-release- New binary: ppx-cold [s390x] (mantic-proposed/universe) [0.16.0-1] (no packageset)
[11:55] -queuebot:#ubuntu-release- New binary: haskell-sdl2-mixer [s390x] (mantic-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[11:55] -queuebot:#ubuntu-release- New binary: ppx-enumerate [s390x] (mantic-proposed/universe) [0.16.0-1] (no packageset)
[11:56] -queuebot:#ubuntu-release- New binary: ppx-globalize [s390x] (mantic-proposed/universe) [0.16.0-1] (no packageset)
[11:57] -queuebot:#ubuntu-release- New binary: haskell-sdl2-image [armhf] (mantic-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[12:09] -queuebot:#ubuntu-release- New binary: haskell-sdl2-mixer [armhf] (mantic-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[12:20] -queuebot:#ubuntu-release- New binary: vfu [riscv64] (mantic-proposed/universe) [5.09-2] (no packageset)
[12:29] -queuebot:#ubuntu-release- New binary: ppx-cold [riscv64] (mantic-proposed/universe) [0.16.0-1] (no packageset)
[12:30] -queuebot:#ubuntu-release- New binary: ppx-enumerate [riscv64] (mantic-proposed/universe) [0.16.0-1] (no packageset)
[12:30] -queuebot:#ubuntu-release- New binary: ppx-globalize [riscv64] (mantic-proposed/universe) [0.16.0-1] (no packageset)
[13:13] -queuebot:#ubuntu-release- New binary: haskell-sdl2-image [riscv64] (mantic-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[13:36] -queuebot:#ubuntu-release- Builds: Ubuntu Unity Desktop amd64 [Mantic Daily] has been updated (20230624)
[13:42] -queuebot:#ubuntu-release- New binary: haskell-sdl2-mixer [riscv64] (mantic-proposed/universe) [<IP_ADDRESS>-2] (no packageset)
[14:52] -queuebot:#ubuntu-release- New binary: cvc5 [riscv64] (mantic-proposed/universe) [1.0.5-3] (no packageset)
[15:38] -queuebot:#ubuntu-release- Unapproved: cups (jammy-proposed/main) [2.4.1op1-1ubuntu4.4 => 2.4.1op1-1ubuntu4.5] (core, i386-whitelist)
[15:48] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Mantic Daily] has been updated (20230624)
[17:03] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Mantic Daily] has been updated (20230624)
[17:18] -queuebot:#ubuntu-release- New binary: libjodycode [amd64] (mantic-proposed/universe) [3.0.1-4] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: sabctools [amd64] (mantic-proposed/none) [7.0.2-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: ufl [amd64] (mantic-proposed/universe) [1:2022.2.0+legacy20230618.20a231f-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: libjodycode [armhf] (mantic-proposed/universe) [3.0.1-4] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: libjodycode [s390x] (mantic-proposed/universe) [3.0.1-4] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: sabctools [s390x] (mantic-proposed/none) [7.0.2-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: libjodycode [ppc64el] (mantic-proposed/universe) [3.0.1-4] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: sabctools [ppc64el] (mantic-proposed/none) [7.0.2-1] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: libjodycode [arm64] (mantic-proposed/universe) [3.0.1-4] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: sabctools [arm64] (mantic-proposed/none) [7.0.2-1] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: sabctools [armhf] (mantic-proposed/none) [7.0.2-1] (no packageset)
[17:30] -queuebot:#ubuntu-release- New binary: libjodycode [riscv64] (mantic-proposed/universe) [3.0.1-4] (no packageset)
[17:37] -queuebot:#ubuntu-release- New binary: sabctools [riscv64] (mantic-proposed/universe) [7.0.2-1] (no packageset)
[18:59] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Mantic Daily] has been updated (20230624)
[23:19] -queuebot:#ubuntu-release- New binary: fenics-basix [amd64] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: fenics-basix [armhf] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: fenics-basix [s390x] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: fenics-basix [arm64] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: fenics-basix [ppc64el] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:52] -queuebot:#ubuntu-release- New binary: fenics-basix [riscv64] (mantic-proposed/universe) [0.6.0-2] (no packageset)