[03:00] <JohnC> hola de que se trata esto?
[07:13] <Neo31> Hello, does the meeting start at 18:05 UTC ?
[14:54] <fginther> good [morning|afternoon|evening|night]
[14:55] <fginther> cjohnston, do you know who is running this track?
[14:55] <ogasawara> fginther: hi, https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
[14:55] <fginther> ogasawara, thanks!
[14:58] <fginther> cjohnston, Ursinha, want to join the hangout?
[14:58] <Ursinha> fginther, sure
[14:58] <cjohnston> not sure I need to
[14:58] <fginther> https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
[14:59] <Ursinha> cjohnston, worst case you won't say a thing :)
[15:00] <fginther> Saviq, want to join the hangout? https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
[15:03]  * tedg puts on his asbestos suit, let's rock!  :-)
[15:03] <dobey> tedg: heh
[15:03] <fginther> tedg, dobey, either of you want to join the hangout?
[15:03] <fginther> https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
[15:03] <fginther> anyone else ^
[15:03] <dobey> i can i guess
[15:03] <tedg> fginther, Sure
[15:04]  * tedg does his hair
[15:04] <Ursinha> haha
[15:04] <fginther> https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
[15:07] <josepht> lower thirds please :)
[15:09] <sergiusens> tedg, we did have ddebs for most of the manhattan stuff
[15:09] <tedg> sergiusens, Yeah, I know, I just want to ensure it's a feature into the future.
[15:11] <cwayne> what is the timeframe for these changes?
[15:14] <cwayne> awesome, thanks
[15:16] <dobey> no lower third with no camera :)
[15:16] <dobey> josepht: ^^ just saw your comment
[15:18] <sergiusens> I have lots of questions, but they don't seem in scope
[15:18] <sergiusens> how is the emulator going to solve the ci problems?
[15:18] <fginther> sergiusens, ask anyway :-)
[15:18] <sergiusens> is click testing tied to the emulator?
[15:19] <cwayne> there is still going to be *some* actual hw testing right?
[15:19] <cwayne> or will that just be sergiusens's papi testing?
[15:20] <sergiusens> Saviq, we actually don't do that for clicks either
[15:20] <tedg> Saviq, I've always viewed QML as a cry for help, nice to hear you say so too!  ;-)
[15:20] <sergiusens> cwayne, lol, I cannot not laugh when reading papi testing
[15:20] <dobey> heh
[15:20] <cwayne> sergiusens, lol i know, i love it
[15:21] <mzanetti> :D
[15:21] <cwayne> but is that testing going to be the only hw testing now?
[15:22] <cwayne> i mean, we do need some level of hw testing obviously, but i see where it would make more sense for apps to be tested on emulators
[15:22] <dobey> there really should be no reason to test on actual hardware, for things that don't talk directly to hardware; for mir it makes sense, for a unity scope, not so much
[15:23] <mzanetti> Saviq: well, you could probably hook into the JS engine and check read/write access of public properties
[15:23] <mzanetti> tedg: in qml _every_ line is "executed" at startup
[15:23] <tedg> mzanetti, Okay, I've got some recommendations for speeding up startup then :-)
[15:24] <mzanetti> tedg: you need to read it to know when to creat it
[15:24] <mzanetti> so you need to read the file at least once. and that's what happening - at the startup
[15:24] <cwayne> dobey, right, i'm +1 ont hat, but just making sure we will still have some baremetal testing, even if it is just for mir for example
[15:25] <tedg> mzanetti, You need to read the file, but you don't need to create objects based on it or parse deeper than "oh, I'll need this someday"
[15:25] <mzanetti> Sarvatt: but that you can count
[15:25] <mzanetti> Saviq: ^ - but sure it's really not trivial
[15:26] <Saviq> mzanetti, yeah, for bindings, we'd have to see whether all the branches were executed
[15:26] <mzanetti> tedg: well, depending on how you write it, they are not created. but still interpreted
[15:26] <doanac`> real h/w testing will continue. we just want to find a better balance between that and virtualized to increase scalability and reliability.
[15:26] <cwayne> +1 on that
[15:26] <cwayne> i'd +more-than-1 if i could :)
[15:26] <tedg> mzanetti, Makes sense, so code coverage would be when objects are created, not interpreted.
[15:27] <sergiusens> fginther, click packages require ubuntu touch
[15:27] <mzanetti> tedg: I'm thinking more about "used" instead of "created". but yeah, something along those lines
[15:27] <fginther> sergiusens, wouldn't that work on a touch emulator?
[15:27] <Ursinha> sergiusens, join the hangout? :)
[15:27] <sergiusens> fginther, I suggest you try to run the emulator on the cloud now that it's there ;-)
[15:33] <dobey> sergiusens: can you add the lower third?
[15:34] <sergiusens> dobey, sure, should be automatic :-)
[15:34] <fginther> ogasawara, you can close the hangout now
[15:35] <ogasawara> thanks, will do
[15:36] <doanac`> thanks fginther
[15:36] <fginther> thanks all!
[15:37] <cwayne> thanks guys!
[16:00] <ogasawara> https://plus.google.com/hangouts/_/7ecpi1hhd2cgo0j1h4c242ik7k?authuser=0&hl=en
[16:02] <ogra_> lool, want to be in the fishbowl ?
[16:02] <ogasawara> apw, lool, rsalveti: ^^ fyi
[16:05] <rsalveti> joining in
[16:06] <ogra_> https://plus.google.com/hangouts/_/7ecpi1hhd2cgo0j1h4c242ik7k?authuser=0&hl=en
[16:06] <ogra_> sforshee, intrested in being in the fishbowl ?
[16:07] <ricmm> im interested
[16:07] <ricmm> to not talk
[16:07] <ogra_> heh
[16:07] <sforshee> ogra_: I'll jump in if needed
[16:08] <sforshee> ogra_: I'm a bit under the weather, so if I don't have anything to contribute then there's no reason to make everyone watch me blowing my nose ;-)
[16:09] <lool> heya
[16:09] <lool> which is that
[16:09] <ogra_> https://plus.google.com/hangouts/_/7ecpi1hhd2cgo0j1h4c242ik7k?authuser=0&hl=en
[16:12] <sforshee> rsalveti: you don't want powerd, if anything upower
[16:12] <sforshee> rsalveti: but the battery information is in /sys/class/power_supply
[16:13] <sforshee> ogra_: the kernel provides the abstraction: /sys/class/power_supply
[16:13] <sforshee> though some logic is needed to figure out the right place to get the battery status
[16:14] <sforshee> let me join
[16:14] <cking> the reliability of the data can be platform specific though
[16:16] <ogra_> ChickenCutlass, https://plus.google.com/hangouts/_/7ecpi1hhd2cgo0j1h4c242ik7k?authuser=0&hl=en
[16:16]  * cking notes that a 1% charge could be a long time on some large batteries
[16:18] <cking> some devices, 1% may be a very short time, so it may be device specific, e.g. 5 mins? 10 mins? 20 seconds? ;-)
[16:18] <ogra_> http://pad.ubuntu.com/uds-1311-core-1311-low-battery-boot-mode
[16:25] <jodh> ogra_: /etc/init/friendly-recovery.conf
[16:26] <jodh> ogra_: we just need to change /usr/share/initramfs-tools/init to pass the custom startup event see last line of that file.
[16:26] <jodh> ogra_: last 2 lines :)
[16:31] <jodh> ogra_: subvert the boot if battery is low (as above). When battery level > some threshold, "initctl emit startup" to resume normal boot.
[16:32] <ogra_> yeah
[16:36] <jodh> np! :)
[16:37] <ogra_> ogasawara, you can stop the recording
[16:37] <ogra_> and thanks all, for coming !"
[16:37] <ogasawara> ogra_: thanks, done.
[17:59]  * rsalveti waves
[18:00] <rsalveti> https://plus.google.com/hangouts/_/76cpiorbncb4s4j02ib1noi6is?authuser=0&hl=en it seems
[18:01] <rsalveti> http://pad.ubuntu.com/uds-1311-core-1311-touch-emulator
[18:01] <rsalveti> pmcgowan: ^
[18:02] <rsalveti> is zoltan around?
[18:02] <pmcgowan> rsalveti, he is but cannot joing the HO
[18:02] <alecu> hola!
[18:02] <rsalveti> we need someone from CI
[18:03] <rsalveti> plars: ^?
[18:03] <dkessel> is there already some preview version of the emulator?
[18:03] <rsalveti> dkessel: yup
[18:03] <rsalveti> dkessel: https://lists.launchpad.net/ubuntu-phone/msg05195.html
[18:05] <dkessel> rsalveti, ah, a normal package... nice :)
[18:05] <bzoltan> rsalveti: I do not join to the hangout because I am still mute
[18:08] <pmcgowan> bzoltan, ping me if I need to hop on the session
[18:08] <bzoltan> pmcgowan:  OK
[18:12] <bzoltan> Yes
[18:12] <bzoltan> rsalveti:  Yes,
[18:13] <bzoltan> rsalveti: Yes, you start the emlator and it works with the QtC out of box
[18:13] <ogra_> bzoltan, oh, it does already ?
[18:13] <ogra_> thats cool
[18:13] <bzoltan> rsalveti:  The emulator is just an adb device
[18:13] <ogra_> (and fast ... for two days)
[18:14] <bzoltan> ALL
[18:14] <ogra_> :)
[18:14] <bzoltan> rsalveti:  we backport to PQRS
[18:14] <bzoltan> packaging is cool
[18:14] <ogra_> ++
[18:15] <Neo31> packaging yes
[18:15] <janimo> it's cool unless the target is fast moving :)
[18:15] <bzoltan> at the SDK team we move fast ...
[18:16] <bzoltan> rsalveti:  we need to fix the adb port forwarding and small things
[18:17] <bzoltan> +1
[18:18] <bzoltan> yes
[18:18] <bzoltan> it is a single line
[18:18] <ogra_> whats wrong with ssh ?
[18:18] <bzoltan> ogra_:  QtC uses adb
[18:19] <bzoltan> No
[18:19] <bzoltan> I need to fix the QtC scripts
[18:19] <bzoltan> Yes
[18:19] <bzoltan> It is QtC side
[18:19] <bzoltan> :D
[18:19] <bzoltan> there is a delay
[18:19] <bzoltan> sorry
[18:20] <ogra_> are we ? i thought we grab the tarball from scimge
[18:20] <ogra_> *cdimage
[18:21] <bzoltan> rsalveti:  may I have a minimal rootsrap to use as a builder? We have click chroot as main target... but a fully emulated native builder would be cool as fallback
[18:21] <ogra_> bzoltan, that will be slow as hell
[18:21] <bzoltan> rsalveti: or an R&D enabled image
[18:21] <bzoltan> ogra_:  it is not that slow ...
[18:22] <ogra_> bzoltan, qemu only emulates a 400MHz single core
[18:22] <bzoltan> ogra_: I just have built the UITK in the emulator
[18:22] <sergiusens> bzoltan, did you try building on the emulator?
[18:22] <sergiusens> and thats faster that a qemu chroot?
[18:22] <bzoltan> sergiusens:  I did not _TRY_
[18:22] <bzoltan> sergiusens:  I did :)
[18:22] <ogra_> bzoltan, if you want a qemu-system based emulator to build in there are way better options
[18:23] <bzoltan> ogra_:  I know ...
[18:23] <ogra_> (we have a qemu highbank option afaik ... )
[18:23] <bzoltan> ogra_: I need to talk to you about it
[18:23] <ogra_> sure
[18:23] <ogra_> :)
[18:23] <fginther> plars, has emulator on a VM (cloud) been discussed?
[18:23] <plars> fginther: not yet
[18:24] <plars> fginther: should be possible I would think, but it may be awfully slow
[18:24] <fginther> plars, sergiusens expressed some concerns other then slowness in a prior session
[18:24] <plars> fginther: I was going to ask about it, since I know it's something we want to do :)
[18:24] <fginther> thx
[18:29] <Saviq> Ctrl+F12 to rotate
[18:29] <Saviq> ChickenCutlass, rsalveti, sergiusens ↑
[18:29] <ChickenCutlass> Saviq, nice
[18:29] <ChickenCutlass> ok
[18:29] <ogra_> wow
[18:30] <ogra_> that works really nicely
[18:30] <Saviq> ogra_, didn't rotate the browser for me, though
[18:31] <ogra_> well, still booting here
[18:31] <ogra_> but i can rotate while it boots :)
[18:31] <ogra_> lol
[18:31] <ogra_> and comes up sideways
[18:31] <Saviq> ogra_, see! it emulates real life ;)
[18:31] <MacSlow> ogra_, Saviq: true real-world case :)
[18:31] <ogra_> heh
[18:32] <rsalveti> Saviq: awesome, need to give it a try
[18:32] <Saviq> rsalveti, so it just looks like the sensor does not give up the rotation change
[18:32] <Saviq> rsalveti, so just more hw enablement
[18:32] <rsalveti> Saviq: right
[18:32] <ogra_> yeah, browser is sideways here
[18:32] <rsalveti> should be easy to fix :-)
[18:32] <ogra_> i guess we need some sensor hook-up
[18:33] <jdstrand> QUESTION: can we look into a snapshot option? it doesn't have to be complicated-- use qcow2 disk and add --snapshot and --revert options to run-emulator. this will allow developers to easily revert to a pristine snapshot, which is highly useful for testing
[18:33] <ogra_> poer button doesnt work either etc ... i guess thats similar
[18:33] <ogra_> jdstrand, only if that ancient qemu supports that ... and we dont have qcow images atm
[18:34] <jdstrand> ancient qemu should support snaphost, but if not you could also use backing store
[18:34] <jdstrand> s/snaphost/snapshot/
[18:34] <asac> so feels if we do real driver testing we need a maas cloud
[18:34] <Saviq> FYI: more keyboard shortcuts http://developer.android.com/tools/help/emulator.html#KeyMapping
[18:34] <asac> so we can provision on bare metal etc.
[18:34] <asac> or can we share drivers across multiple VMs?
[18:35] <ogra_> what do you mean by drivers exactly ?
[18:35] <jdstrand> technically, it could be opt in-- you could use qemu-img to convert to qcow2 after downloading the image
[18:35] <asac> if we have servers with GPUs :)
[18:35] <ogra_> oh, yeah, the server definitely needs the GPU
[18:35] <asac> we could run them on bare metal and use GL properly... otherwise i assumed we would just run against software mesa
[18:35] <ogra_> most likely even running X
[18:35] <asac> etc.
[18:35] <asac> in virtual... but might be too slow
[18:36] <ogra_> or xvfb ... not sure that provides GL
[18:36] <asac> right. but our current machines ... namely otto etc. are always busted
[18:36] <asac> because we do raw GPU testing
[18:36] <ogra_> then we need a dedicated machine
[18:36] <asac> so we need maas to automatically recover rather then alwys do manual maintenance
[18:36] <jdstrand> image snapshotting doesn't have to be complicated btw. people can get super clever-- only really need snapshot and revert to snapshot
[18:36] <ogra_> desktop class machine ...
[18:37] <asac> desktop is where the test machines always hang
[18:37] <asac> because of GPU crashes
[18:37] <asac> -> e.g. that should be maas with automatically reflashing machines with a safe iamge
[18:37] <ogra_> asac, right, it wouldnt put any load on the GPU
[18:37] <ogra_> but it needs something at the desktop end to hand through the GL
[18:37] <ogra_> so you need some X server/Xvfb etc running
[18:38] <asac> sure. X would run etc.
[18:38] <asac> if we want to use pass through... still needs to be maased etc.
[18:39] <asac> IT WILL MESS UP TIMEOUTS :)
[18:39] <jdstrand> ogra_: what version of qemu is it based on?
[18:39] <asac> and we should fix those
[18:39] <asac> hehe
[18:39] <ogra_> jdstrand, dunno, but likely older than your grandma ...
[18:39] <ogra_> rsalveti knwos i think
[18:40] <ogra_> 0.9 or some such ?
[18:40] <jdstrand> I was doing backing stores with qemu a *long* time ago
[18:40] <asac> i think the emulator is well usable ... even though pretty slow. the problem i see is just how i can do gestures. can we mayb hook the buttons up to various gestures?
[18:40] <asac> like the home button gets the swipe to home?
[18:40] <ChickenCutlass> asac, yes, that would be good.
[18:41] <asac> rsalveti: ChickenCutlass: ^^
[18:41] <doanac`> do we have a ppa from the emulator or is it just packaged for trusty?
[18:41] <ogra_> asac, the buttons should go away
[18:41] <asac> oh already answered
[18:41] <sergiusens> I thought we'd remove all buttons :-P
[18:41] <ogra_> ++
[18:41] <asac> ogra_: we can use different images... doing a swipe is not very easy with mouse
[18:41] <ogra_> well, we should keep power and volume
[18:41] <asac> and especially in slowness for now
[18:41] <ogra_> asac, works for me ... you need to be patient :)
[18:41]  * Saviq just started a unity8 autopilot run
[18:41] <asac> so having a button to do a full left/right/up/down swipe
[18:41] <asac> would be good for productivity
[18:42] <ChickenCutlass> ogra_, asac the performance is good for me.
[18:42] <ogra_> yeah, same here
[18:42] <ChickenCutlass> need to wait until the system settles
[18:42] <asac> if it is triggered by emulator
[18:42] <Saviq> please let's not hook into unity
[18:42] <asac> it should come from hardware as a swipe at best :)
[18:42] <Saviq> or well, at most through autopilot
[18:43] <Saviq> UInputError: "/dev/uinput" does not exist or is not a character device file
[18:43] <Saviq> plars, ↑ when trying to run autopilot tests
[18:43] <ogra_> Saviq, autopilot wont be there for devs (for their brandnew app they test)
[18:43] <Saviq> ogra_, ap is seeded
[18:43] <ogra_> sure
[18:43] <ogra_> but if you are $random_dev you want to get your app done
[18:43] <asac> yeah maas is a CI engine topic to explore
[18:44] <asac> e.g. how to provisionm good worker nodes for the emulator
[18:44] <jdstrand> I'm curious now
[18:44] <MacSlow> Question: Will there be (command-line) switches to select a specific device to emulate (N4, N10 etc)?
[18:44] <ogra_> MacSlow, lol, no
[18:44] <jdstrand> I think I'll play with something (ridiculously rough) to see if we can do backing stores or snapshots
[18:44] <ogra_> MacSlow, it is completely based on the goldfish qemu emulator from google
[18:45] <MacSlow> ogra_, ok
[18:45] <ogra_> MacSlow, to get other device emu, you would have to write a complete qemu machine that emulates that device
[18:45] <ogra_> MacSlow, currently we are limited to a single core 400MHz CPU with 512M ram
[18:46] <Saviq> ogra_, probably depends on what MacSlow meant to select a device
[18:46] <Saviq> ogra_, one of the more important things is the resolution, which obviously would be available
[18:46] <ogra_> we will enable different screen resolutions
[18:46] <ogra_> that was discussed
[18:46] <ogra_> but we cant easily emulate another HW
[18:46] <asac> rsalveti: ChickenCutlass: also we want landscape/portrait mode
[18:46] <Saviq> yeah, not sure what else is different between devices
[18:46] <asac> is that something the emulator need to support?
[18:46] <ChickenCutlass> asac, yup, already covered that
[18:46] <MacSlow> ogra_, Saviq: well mostly default orientation and resolution... CPU/GPU not so much atm
[18:46] <asac> ah ok
[18:46] <asac> thanks
[18:46] <Saviq> asac, Ctrl+F12
[18:46] <ChickenCutlass> asac, already does
[18:47] <ogra_> MacSlow, that will be supported
[18:47] <MacSlow> ogra_, ok
[18:47] <asac> ok. nice on accell and orientation
[18:47] <ogra_> rsalveti, that was mostly about resolutions
[18:48] <asac> is someone from sdk in the sessionm?
[18:48] <bzoltan> _YES_
[18:48] <ogra_> asac, bzoltan is here
[18:48] <ogra_> (all the time)
[18:48] <ogra_> :)
[18:48] <asac> well. you cant see that in hyoutube
[18:48] <bzoltan> I am listening
[18:48] <asac> if you dont have a pic :)
[18:48] <ogra_> he isnt in the hangout
[18:49] <asac> would be nice to hear what the sdk vision is
[18:49] <asac> though
[18:49] <asac> anyway :)
[18:49] <asac> yeah ok
[18:49] <bzoltan> I am here!
[18:49] <ogra_> was discussed above
[18:49] <bzoltan> :)
[18:49] <ogra_> read the backlog
[18:49] <bzoltan> asac: I am temporarily mute
[18:49] <asac> ok sorry
[18:49] <Saviq> there's prior art on QtCreator + emulator
[18:49] <asac> hard to catch up on a video stream :)
[18:49] <Saviq> for MeeGo at least
[18:49] <asac> and then match the irc backlog
[18:49] <asac> hehe
[18:50] <Ursinha> lol
[18:50] <ogra_> asac, yeah, the important stuff happened in the IRC channel anyway
[18:50] <bzoltan> Saviq:  I know... I was working on it :)
[18:50] <ogra_> ignore the guys on youtube :P
[18:50] <Saviq> bzoltan, good!
[18:50] <ogra_> they just fill the pad over there
[18:50] <bzoltan> ogra_: they should join here and stop the crap there :)
[18:50] <ogra_> yeah
[18:51] <bzoltan> good stuff
[18:51] <Saviq> o/
[18:51] <ogra_> ++
[18:51] <MacSlow> Question: Regarding autopilot... ap-test passing on real hardware, but failing on the emulator will be considered an autopilot-binding bug on the emulator, right?!
[18:51] <bzoltan> MacSlow: nomen est omen :)
[18:51] <ogra_> MacSlow, they will have to be researched
[18:52] <Saviq> MacSlow, rather a bug in the test
[18:52] <rsalveti> emulator will be the first target
[18:52] <ogra_> we cant just blame the emulator, we have to look at the reasoning etc
[18:52] <rsalveti> can't fail in the emulator
[18:52] <MacSlow> Saviq, really?
[18:52] <rsalveti> can fail in devices, but still be critical
[18:52] <Saviq> MacSlow, if something would fail on the emulator, but pass on devices
[18:52] <Saviq> MacSlow, means it wouldn't pass on a high-load device either
[18:53] <jdstrand> ah
[18:53] <Saviq> MacSlow, 'cause that would just be timing-related
[18:53] <jdstrand> version 0.12.0
[18:53] <ogra_> jdstrand, oh, that new !
[18:53] <Saviq> MacSlow, so you'll need to make the test more robust
[18:53] <jdstrand> external/qemu/Changelog
[18:53]  * ogra_ expected older actually
[18:53] <MacSlow> Saviq, ok... in that particular case (timing) I'd agree...
[18:53] <ogra_> o would have put my bets on 0.8 or 0.9
[18:53] <jdstrand> so, qemu-img still defaults to compat=0.10
[18:53] <Saviq> MacSlow, any other reason - as ogra_ said, would need to be investigatesd
[18:53] <Saviq> -s
[18:53] <jdstrand> so I think we should be ok with at least backing store (which is usable)
[18:54] <Saviq> MacSlow, but that should be really rare
[18:54] <MacSlow> Saviq, I hope so
[18:54] <rsalveti> jdstrand: cool
[18:54] <MacSlow> I'm good
[18:54] <Saviq> MacSlow, good thing is - Ubuntu in there doesn't even know it's running on an emulator
[18:54] <jdstrand> so, let me play with this
[18:54] <rsalveti> jdstrand: :D
[18:54] <jdstrand> I can resurrect some old scripts and maybe hand them off
[18:54] <Saviq> MacSlow, from our PoV it's just another device - albeit a slow one
[18:54] <Saviq> summary time
[18:55] <MacSlow> Saviq, ~4 times slower than a N10 I'd say
[18:56] <jdstrand> oh, that was fast. /me found the scripts :)
[18:56] <MacSlow> Saviq, ogra_: I'll give it a shot tomorrow


[00:11] <mwhudson> ubuntu-archive: could someone please remove the armhf binaries for eckit, fckit, metkit
[00:11] <mwhudson> (does this need a bug?)
[00:14] <RAOF> Not necessarily.
[00:15] <mwhudson> hm is this on?
[00:15] <RAOF> It looks like you're asking for that because those source packages no longer build armhf binaries?
[00:15] <mwhudson> RAOF: ah hi :)
[00:15] <mwhudson> RAOF: yes
[00:15] <mwhudson> the binaries have been removed in debian
[00:15] <mwhudson> https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=unstable;include=subject%3Aeckit;package=ftp.debian.org
[00:17] <mwhudson> hm probably want the other two packages there to be removed too
[00:17] <RAOF> Huh. The metkit in jammy-proposed still seems to build armhf binaries?
[00:18] <mwhudson> hmm
[00:20] <mwhudson> hmm https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993624 says that metkit was fixed but it doesn't look like that happened
[00:34] <mwhudson> RAOF: anyway, even if the next upload of metkit doesn't update the architectures, if the binaries for the dependencies have been removed, the armhf builds will just depwait and cause no migration issues?
[00:34] <mwhudson> or i can do a quick metkit upload with that change
[00:34] <mwhudson> RAOF: would be nice to get this dealt with thouth
[00:35] <RAOF> Yeah, I'm just checking that there's no other rdepends.
[00:35] <mwhudson> thx
[00:35] <RAOF> Yeah, metkit will just depwait on armhf and everything will be unicorns.
[00:40] <bryyce> utkarsh2102, to spare everyone here a wall of text, I've dropped the notes here:  https://paste.ubuntu.com/p/kSmWDwDvh9/
[00:41] <bryyce> utkarsh2102, I've also updated https://wiki.ubuntu.com/ServerTeam/Transition/Php8.1 with summarized info
[00:45] -queuebot:#ubuntu-release- New binary: mariadb-10.6 [armhf] (jammy-proposed/universe) [1:10.6.4-1] (no packageset)
[00:54] <RAOF> Looks like we also need magics++.
[00:56] <bryyce> @utkarsh2102 @vorlon php-codecoverage 9.2.8 now builds successfully for me locally, I'm trying a simple LP rebuild but it may need a no-change rebuild uploaded
[01:01] <bryyce> @utkarsh no dice on simple LP rebuild, uploading no-change rebuild.  Please check on status when you BOD.
[01:16] <RAOF> mwhudson: Ok, I *think* all the relevant armhf packages are cleaned up now. A bunch (odc, fdb, metview, magic++, atlas-ecmwf) already weren't built for armhf, leaving just eckit, fckit and metkit.
[01:16] <mwhudson> RAOF: woo thanks
[02:58] <mwhudson> ubuntu-archive: can ruby3.0 be added to the i386-whitelist pls
[04:20] <ginggs> xnox: i see that in the r-bioc-affy autopkgtest.  i tried again now with r-bioc-biocgenerics/0.38.0-1 from -proposed and it passed.
[04:21] <ginggs> also, the tests that were failing with 'Fortran complex functions are not available on this platform' also passed
[04:22] <ginggs> so i think your upload was good and no rebuilds needed
[04:58] -queuebot:#ubuntu-release- New binary: mariadb-10.6 [riscv64] (jammy-proposed/universe) [1:10.6.4-1] (no packageset)
[05:04] <vorlon> mwhudson: done
[05:04] <vorlon> mwhudson: (and building)
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libanyevent-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libasync-interrupt-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libcanary-stability-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libcommon-sense-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libev-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libevent-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libfilter-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libfreenect from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libfuture-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libio-async-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libio-pipely-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libmetrics-any-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libpoe-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libstruct-dumb-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libtest-metrics-any-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed libunicode-utf8-perl from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Removed perl-tk from i386-whitelist in jammy
[05:20] -queuebot:#ubuntu-release- Packageset: Added platformdirs to i386-whitelist in jammy
[05:21] -queuebot:#ubuntu-release- Packageset: Added pybind11 to i386-whitelist in jammy
[05:21] -queuebot:#ubuntu-release- Packageset: Added ruby3.0 to i386-whitelist in jammy
[05:31] -queuebot:#ubuntu-release- New binary: obs-advanced-scene-switcher [amd64] (jammy-proposed/none) [1.15.3+git20210913.25cf51a-2] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: obs-advanced-scene-switcher [ppc64el] (jammy-proposed/none) [1.15.3+git20210913.25cf51a-2] (no packageset)
[05:36] -queuebot:#ubuntu-release- New binary: obs-advanced-scene-switcher [arm64] (jammy-proposed/none) [1.15.3+git20210913.25cf51a-2] (no packageset)
[07:12] <mwhudson> vorlon: thanks
[09:11] <ginggs> xnox: btw, the R tests with complex functions all passed with r-base built with LTO in my PPA, both with all-proposed and without
[09:28] -queuebot:#ubuntu-release- Unapproved: mesa (focal-proposed/main) [21.0.3-0ubuntu0.3~20.04.3 => 21.0.3-0ubuntu0.3~20.04.4] (core, i386-whitelist, xorg)
[12:23] <xnox> ginggs:  nice!
[12:51] <ginggs> and it looks like r-base is migrating now \o/
[13:30] -queuebot:#ubuntu-release- New sync: openjdk-17 (xenial-proposed/primary) [17~11-1~16.04~2]
[13:31] -queuebot:#ubuntu-release- Unapproved: openjdk-17 (bionic-proposed/universe) [17+35-1~18.04 => 17.0.1+12-1~18.04] (no packageset) (sync)
[13:31] -queuebot:#ubuntu-release- Unapproved: openjdk-17 (focal-proposed/universe) [17+35-1~20.04 => 17.0.1+12-1~20.04] (i386-whitelist) (sync)
[13:31] -queuebot:#ubuntu-release- Unapproved: openjdk-17 (hirsute-proposed/universe) [17+35-1~21.04 => 17.0.1+12-1~21.04] (i386-whitelist) (sync)
[13:32] -queuebot:#ubuntu-release- Unapproved: openjdk-17 (impish-proposed/universe) [17+35-1 => 17.0.1+12-1~21.10] (i386-whitelist) (sync)
[13:46] -queuebot:#ubuntu-release- Unapproved: libreoffice (focal-backports/main) [1:6.4.7-0ubuntu<IP_ADDRESS> => 1:7.1.7-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[14:41] <doko> amurray, libseccomp ftbfs, bogus check in debian/rules: python3 -c "pyver='$$pyver'; exit(0 if float(pyver[6:]) >= 3.8 else 1)"
[14:43] -queuebot:#ubuntu-release- New: rejected openjdk-17 [sync] (xenial-proposed) [17~11-1~16.04~2]
[14:59] <tjaalton> rbasak: hi, I've added some more info on the focal mesa sru bug, hope it's enough
[15:14] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (focal-proposed) [21.0.3-0ubuntu0.3~20.04.4]
[15:14] <rbasak> tjaalton: accepted. Though I don't think you're really answering the "Where things could go wrong" section, it's not worth arguing about.
[15:21] <tjaalton> for trivial things like this a simple "nowhere" should suffice, but I feel that wouldn't help getting it accepted :)
[15:21] <tjaalton> and thanks
[15:30] <rbasak> tjaalton: well, that's explicitly not acceptable by our current policy. I can still think of things that can go wrong. For example, were the right pointers NULLed? Are there any others anywhere that were missed? Is something somewhere relying on it being not NULL?
[15:30] <rbasak> Proving to me that these aren't the case isn't the point. Identifying the area of code/testing that could identify a mistake here is the point.
[15:31] <rbasak> Is the pointer definitely valid at the point it's being set to NULL? Is the member still valid at the point that some code is now relying on it being NULL?
[17:14] <ginggs> there goes r-bioc-*
[18:00] <blackboxsw> rbasak: maybe it's too late in the day for SRU review. if you get a chance to review the software-properties upload for bionic @ http://launchpadlibrarian.net/567282951/software-properties_<IP_ADDRESS>.17_<IP_ADDRESS>.18.diff.gz it's been hanging out in the unapproved queue for a while. If not, no rush, I'll ping SRU vanguard tomorrow
[18:01] <blackboxsw> this same changeset has undergone my verification on Focal, Hirsute, Impish and Jammy
[18:01] <blackboxsw> just needed to sync functionality for desktop into Bionic
[18:03] <blackboxsw> per bug https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1939732
[18:08] <blackboxsw> ultimately for this review we want to replace the current software-properties_<IP_ADDRESS>.17 in bionic-proposed with <IP_ADDRESS>.18   https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1920836/comments/40
[18:18] <bdmurray> blackboxsw, rbasak: I can have a look at this
[18:18] <blackboxsw> thanks Brian
[18:20] <bdmurray> blackboxsw: the phrase "please reject <IP_ADDRESS>.17" is confusing. The choices are supersede the existing upload and include the fix for bug 1934439 or supsede and drop the fix for that bug.
[18:21] <bdmurray> well given that the pro banner patch passed verification lets choose include the fix for that
[18:23] <blackboxsw> ahhh right makes sense, didn't realize that the bionic upload also dropped the bug fix. I thought it was put up as supplemental
[18:25] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [<IP_ADDRESS>.18]
[19:15] <ricotz> bdmurray, hello :), could you take a look at this libreoffice backport proposal? https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1950467
[19:16] <bdmurray> ricotz: Is that different than the existing one?
[19:17] <ricotz> bdmurray, this targets focal-backports
[19:17] <bdmurray> ricotz: Oh, I'm not on the backports team
[19:18] <ricotz> bdmurray, oh, I assumed so :), do I have to assign the bug to another team besides ubuntu-release?
[19:25] <bdmurray> ricotz: I'm not sure what the backports team new process is. ddstreet might be able to help
[19:30] <ricotz> bdmurray, I see, thank you
[20:24] -queuebot:#ubuntu-release- Unapproved: rejected cockpit-machines [source] (focal-backports) [255-1~ubuntu20.04.1]
[20:24] -queuebot:#ubuntu-release- Unapproved: rejected cockpit-machines [source] (impish-backports) [255-1~ubuntu21.10.1]
[23:23] -queuebot:#ubuntu-release- New binary: mediawiki-extension-codemirror [amd64] (jammy-proposed/none) [4.0.0~git20210902.a63f3c2-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: node-mdn-browser-compat-data [amd64] (jammy-proposed/none) [4.0.3-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: node-statsd-parser [amd64] (jammy-proposed/none) [0.0.4-1] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: node-strftime [amd64] (jammy-proposed/none) [0.10.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: clpeak [amd64] (jammy-proposed/none) [1.1.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: node-fn.name [amd64] (jammy-proposed/none) [1.1.0-4] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: node-triple-beam [amd64] (jammy-proposed/none) [1.3.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: node-fecha [amd64] (jammy-proposed/none) [4.2.1-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: node-text-hex [amd64] (jammy-proposed/none) [1.0.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: clpeak [ppc64el] (jammy-proposed/none) [1.1.0-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: harmonypy [amd64] (jammy-proposed/none) [0.0.5-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gnome [amd64] (jammy-proposed/none) [41.0-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: zycore-c [amd64] (jammy-proposed/none) [1.0.0-1] (no packageset)
[23:30] -queuebot:#ubuntu-release- New binary: pcm [amd64] (jammy-proposed/none) [202110-1] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: clpeak [arm64] (jammy-proposed/universe) [1.1.0-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: zycore-c [arm64] (jammy-proposed/universe) [1.0.0-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: zycore-c [armhf] (jammy-proposed/universe) [1.0.0-1] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: clpeak [riscv64] (jammy-proposed/universe) [1.1.0-1] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gnome [arm64] (jammy-proposed/universe) [41.0-1] (no packageset)
[23:36] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gnome [ppc64el] (jammy-proposed/universe) [41.0-1] (no packageset)
[23:36] -queuebot:#ubuntu-release- New binary: clpeak [armhf] (jammy-proposed/universe) [1.1.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: clpeak [s390x] (jammy-proposed/universe) [1.1.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gnome [s390x] (jammy-proposed/universe) [41.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gnome [armhf] (jammy-proposed/universe) [41.0-1] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gnome [riscv64] (jammy-proposed/universe) [41.0-1] (no packageset)
[23:58] -queuebot:#ubuntu-release- New binary: mrgingham [riscv64] (jammy-proposed/universe) [1.20-1] (no packageset)