[00:02] <mwhudson> vorlon: have you tried beignet without lto?
[00:02] <vorlon> mwhudson: I don't remember.  It's possible, but I haven't looked at it in over a month
[00:03] <mwhudson> i *think* lto is just making this harder to debug but ...
[00:10] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (focal-proposed) [1:0.9.0~<IP_ADDRESS>]
[00:14] -queuebot:#ubuntu-release- Unapproved: gnome-connections (jammy-proposed/universe) [42.0-1 => 42.1-1] (no packageset) (sync)
[00:15] <mwhudson> vorlon: also beignet in jammy-proposed explicitly depends on llvm-9, is there a newer version in debian?
[00:15] -queuebot:#ubuntu-release- Unapproved: accepted gnome-connections [sync] (jammy-proposed) [42.1-1]
[00:16] <mwhudson> oh and this is why beignet is not in testing
[00:20] <vorlon> mwhudson: uh I thought the -proposed version was using newer llvm?
[00:21] <mwhudson> vorlon: doesn't look like it
[00:21] <vorlon> mwhudson: ok well, "unreleasable let's remove it" is one solution, thanks
[00:21] <mwhudson> (lto doesn't fix the build fwiw)
[00:21] <mwhudson> vorlon: ack
[00:21] <mwhudson> what does this software do anyway :)
[00:22] <mwhudson> opencl on intel gpus?
[00:22] <mwhudson> _old_ intel gpus
[00:48] <mwhudson> vorlon: huh mythv seems significantly less installable in jammy than impish, i wonder what is going on there
[01:00] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (impish-proposed) [1:<IP_ADDRESS>~<IP_ADDRESS>]
[01:09] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (impish-proposed) [1:<IP_ADDRESS>~<IP_ADDRESS>]
[01:45] -queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (focal-proposed) [1.5.9-0ubuntu1~20.04.1]
[02:05] <vorlon> mwhudson: I think there may have been some removals along the way, but I don't recall
[02:14] -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (focal-proposed) [20.10.12-0ubuntu2~20.04.1]
[02:18] -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (impish-proposed) [20.10.12-0ubuntu2~21.10.1]
[02:20] -queuebot:#ubuntu-release- Unapproved: mythexport (jammy-proposed/multiverse) [2.2.4-0ubuntu6 => 2.2.4-0ubuntu7] (no packageset)
[02:21] -queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (impish-proposed) [1.5.9-0ubuntu1~21.10.1]
[02:21] -queuebot:#ubuntu-release- Unapproved: accepted mythexport [source] (jammy-proposed) [2.2.4-0ubuntu7]
[05:17] -queuebot:#ubuntu-release- Unapproved: python-dbusmock (jammy-proposed/universe) [0.27.3-1 => 0.27.5-1] (no packageset) (sync)
[05:18] -queuebot:#ubuntu-release- Unapproved: accepted python-dbusmock [sync] (jammy-proposed) [0.27.5-1]
[05:19] -queuebot:#ubuntu-release- Unapproved: cockpit-machines (focal-backports/universe) [263-1~bpo20.04.1 => 265-1~bpo20.04.1] (no packageset)
[05:19] -queuebot:#ubuntu-release- Unapproved: cockpit-machines (impish-backports/universe) [263-1~bpo21.10.1 => 265-1~bpo21.10.1] (no packageset)
[05:20] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-machines [source] (focal-backports) [265-1~bpo20.04.1]
[05:20] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-machines [source] (impish-backports) [265-1~bpo21.10.1]
[06:49] -queuebot:#ubuntu-release- Unapproved: intel-vc-intrinsics (jammy-proposed/universe) [0+git20210816-2 => 0.1.0-2] (no packageset) (sync)
[06:49] -queuebot:#ubuntu-release- Unapproved: accepted intel-vc-intrinsics [sync] (jammy-proposed) [0.1.0-2]
[07:28] -queuebot:#ubuntu-release- Unapproved: libx11 (jammy-proposed/main) [2:1.7.2-2build1 => 2:1.7.5-1] (core, i386-whitelist, xorg) (sync)
[07:35] -queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (jammy-proposed) [1:5.0.0~git2209-g5a7b9ce67-0ubuntu1]
[07:36] -queuebot:#ubuntu-release- Unapproved: accepted libx11 [sync] (jammy-proposed) [2:1.7.5-1]
[07:40] <seb128> hey there, any chance someone could review https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1967127 ?
[07:41] <seb128> it has been waiting for a week, that's making a difference in the testing it will get at this point of the cycle
[07:41] -queuebot:#ubuntu-release- Unapproved: arc-theme (jammy-proposed/universe) [20220223-1 => 20220405-1] (lubuntu, personal-fossfreedom, ubuntu-budgie) (sync)
[07:46] -queuebot:#ubuntu-release- Unapproved: xf86-input-wacom (jammy-proposed/main) [1:0.39.0-0ubuntu3 => 1:1.0.0-3ubuntu1] (desktop-core, xorg)
[07:47] <seb128> would be nice if the bot was posting about FFe bug being reported and status changes
[08:24] <handsome_feng> sil2100: Hi, about LP: #1966321, can I  upload the new ubuntukylin-meta? Since it cause the livefs build errors now: https://launchpadlibrarian.net/595097521/buildlog_ubuntu_jammy_arm64_ubuntukylin_BUILDING.txt.gz
[08:57] -queuebot:#ubuntu-release- Unapproved: libadwaita-1 (jammy-proposed/main) [1.1.0-1 => 1.1.0-1ubuntu1] (no packageset)
[09:18] -queuebot:#ubuntu-release- Unapproved: zsys (focal-proposed/main) [0.4.8 => 0.5.9] (no packageset)
[09:30] -queuebot:#ubuntu-release- Unapproved: rejected zsys [source] (focal-proposed) [0.5.9]
[09:32] -queuebot:#ubuntu-release- Unapproved: zsys (jammy-proposed/main) [0.5.8build2 => 0.5.9] (ubuntu-desktop)
[09:47] <sil2100> handsome_feng: yes! Please do!
[09:47] <sil2100> Switched the FFe bug to Triaged
[09:48] -queuebot:#ubuntu-release- Unapproved: dpkg (jammy-proposed/main) [1.21.1ubuntu1 => 1.21.1ubuntu2] (core, i386-whitelist)
[09:52] <xnox> juliank:  ^^^^ implementing reverted nmu in Ubuntu at least.
[09:54] <handsome_feng> sil2100: Got it, Thank you.
[09:55] -queuebot:#ubuntu-release- Unapproved: iptables-netflow (focal-proposed/universe) [2.4-2ubuntu0.4 => 2.4-2ubuntu0.5] (kernel-dkms)
[10:00] -queuebot:#ubuntu-release- Unapproved: lttng-modules (focal-proposed/universe) [2.12.5-1ubuntu2~20.04.1 => 2.12.5-1ubuntu3~20.04.1] (kernel-dkms)
[10:10] -queuebot:#ubuntu-release- New source: linux-firmware-mediatek-aiot (focal-proposed/primary) [1-0ubuntu0~20.04.1]
[10:19] -queuebot:#ubuntu-release- Unapproved: openafs (focal-proposed/universe) [1.8.4~pre1-1ubuntu2.3 => 1.8.4~pre1-1ubuntu2.4] (kernel-dkms)
[10:23] <juliank> xnox: thank you
[10:34] <xnox> apw:  please reject focal-sru Notice(queuebot): Unapproved: lttng-modules (focal-proposed/universe) [2.12.5-1ubuntu2~20.04.1 => 2.12.5-1ubuntu3~20.04.1] (kernel-dkms) => after a discussion, we now think it is a bad version number.
[10:34] <xnox> or any other ubuntu-sru please.
[10:34] <apw> xnox, looking
[10:35] -queuebot:#ubuntu-release- Unapproved: rejected lttng-modules [source] (focal-proposed) [2.12.5-1ubuntu3~20.04.1]
[10:36] <xnox> tah
[10:43] -queuebot:#ubuntu-release- Unapproved: rtl8812au (focal-proposed/universe) [<IP_ADDRESS>75.20140902+dfsg-0ubuntu13~20.04.3 => <IP_ADDRESS>75.20140902+dfsg-0ubuntu13~20.04.4] (kernel-dkms)
[10:53] -queuebot:#ubuntu-release- New: rejected linux-firmware-mediatek-aiot [source] (focal-proposed) [1-0ubuntu0~20.04.1]
[10:54] -queuebot:#ubuntu-release- Unapproved: rtl8821ce (focal-proposed/universe) [<IP_ADDRESS>-0ubuntu4~20.04.4 => <IP_ADDRESS>-0ubuntu4~20.04.5] (kernel-dkms)
[10:55] -queuebot:#ubuntu-release- New source: linux-firmware-mediatek-aiot (focal-proposed/primary) [1-0ubuntu0~20.04.1]
[10:55] -queuebot:#ubuntu-release- Unapproved: lttng-modules (focal-proposed/universe) [2.12.5-1ubuntu2~20.04.1 => 2.12.5-1ubuntu2~20.04.2] (kernel-dkms)
[10:57] -queuebot:#ubuntu-release- New: accepted linux-firmware-mediatek-aiot [source] (focal-proposed) [1-0ubuntu0~20.04.1]
[11:00] -queuebot:#ubuntu-release- New binary: linux-firmware-mediatek-aiot [arm64] (focal-proposed/none) [1-0ubuntu0~20.04.1] (no packageset)
[11:09] -queuebot:#ubuntu-release- New: accepted linux-firmware-mediatek-aiot [arm64] (focal-proposed) [1-0ubuntu0~20.04.1]
[11:15] -queuebot:#ubuntu-release- Unapproved: accepted arc-theme [sync] (jammy-proposed) [20220405-1]
[11:15] -queuebot:#ubuntu-release- Unapproved: accepted libadwaita-1 [source] (jammy-proposed) [1.1.0-1ubuntu1]
[11:15] -queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (jammy-proposed) [1.21.1ubuntu2]
[11:15] -queuebot:#ubuntu-release- Unapproved: accepted zsys [source] (jammy-proposed) [0.5.9]
[11:23] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-qxl (jammy-proposed/main) [0.1.5+git20200331-2build1 => 0.1.5+git20200331-3] (desktop-core, xorg) (sync)
[11:24] -queuebot:#ubuntu-release- Unapproved: intel-graphics-compiler (jammy-proposed/universe) [1.0.8744-3 => 1.0.10778-1] (no packageset) (sync)
[11:25] -queuebot:#ubuntu-release- Unapproved: accepted intel-graphics-compiler [sync] (jammy-proposed) [1.0.10778-1]
[11:25] <xnox> thank you laney
[11:26] -queuebot:#ubuntu-release- Unapproved: ubuntukylin-meta (jammy-proposed/universe) [0.45 => 0.46] (ubuntukylin)
[11:32] <laney> 💋
[11:53] <tjaalton> xserver-xorg-video-qxl fixes bug 1967901
[13:14] -queuebot:#ubuntu-release- Unapproved: rejected openssl [source] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.16]
[13:19] -queuebot:#ubuntu-release- New source: qemu-efi-noacpi (jammy-proposed/primary) [1.0]
[13:37] -queuebot:#ubuntu-release- Unapproved: accepted ddcci-driver-linux [source] (focal-proposed) [0.3.3-1ubuntu0.1]
[13:38] -queuebot:#ubuntu-release- Unapproved: accepted iptables-netflow [source] (focal-proposed) [2.4-2ubuntu0.5]
[13:42] -queuebot:#ubuntu-release- Unapproved: adsys (jammy-proposed/main) [0.8.3 => 0.8.4] (no packageset)
[13:46] -queuebot:#ubuntu-release- Unapproved: accepted openafs [source] (focal-proposed) [1.8.4~pre1-1ubuntu2.4]
[13:49] -queuebot:#ubuntu-release- Unapproved: accepted rtl8812au [source] (focal-proposed) [<IP_ADDRESS>75.20140902+dfsg-0ubuntu13~20.04.4]
[13:50] -queuebot:#ubuntu-release- Unapproved: accepted rtl8821ce [source] (focal-proposed) [<IP_ADDRESS>-0ubuntu4~20.04.5]
[13:57] -queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (jammy-proposed) [0.46]
[13:58] -queuebot:#ubuntu-release- Unapproved: accepted adsys [source] (jammy-proposed) [0.8.4]
[13:59] -queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-qxl [sync] (jammy-proposed) [0.1.5+git20200331-3]
[14:06] <xnox> laney:  cjwatson: vorlon: should we land https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1921862 https://code.launchpad.net/~laney/ubuntu-archive-publishing/updates/+merge/402698 and https://code.launchpad.net/~jibel/livecd-rootfs/+git/livecd-rootfs/+merge/402585 such that we don't suffer promotions in -updates in jammy later on, again?
[14:13] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (jammy-proposed/main) [2.762 => 2.763] (desktop-core, i386-whitelist)
[14:18] <laney> xnox: probably needs someone to take on driving it, that MP of mine wasn't a complete fix but maybe you want to work on the problem incrementally
[14:22] -queuebot:#ubuntu-release- Unapproved: ubiquity (jammy-proposed/main) [22.04.11 => 22.04.12] (ubuntu-desktop)
[14:29] <xnox> laney:  =(
[14:29] <xnox> meanwhile uploading livecd-rootfs & ubiquity to hopefully have useful and usable installers finally
[14:32] <juliank> I have retried all test failures on amd64
[14:32] <juliank> We just moved off lcy01 and everything to lgw01, that's making sure the move worked fine
[14:33] <juliank> If you need to run lots of tests, let me know and I'll go cancel mine .)
[14:36] -queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.1-1ubuntu2.1~18.04.15 => 1.1.1-1ubuntu2.1~18.04.16] (core)
[14:40] <xnox> vorlon:  sil2100: juliank: dannf_: apw: 	Notice(queuebot): New source: qemu-efi-noacpi (jammy-proposed/primary) [1.0] -> is a package we'd want to use in autopkgtests when testing raspi kernels; as it would allow us to manipulate and make sure scalingstack instances can reboot into raspi kernel.
[14:41] <juliank> +100
[14:41] <xnox> it would be nice to get that into jammy; as we will eventually backport that all the way to bionic.
[14:41] <juliank> xnox: can we just build it in -Zxz and binary copy it everywhere?
[14:42] <vorlon> ahasenack: was there going to be any more work this cycle to build libnfsidmap-regex from nfs-utils?  I'm processing Debian removals right now so just checking
[14:42] <juliank> xnox: or build it in bionic and binary copy it up
[14:42] <juliank> xnox: avoids work :)
[14:42] <vorlon> juliank: binary copy it up> no
[14:42] <ahasenack> vorlon: no
[14:42] <vorlon> you get to do that for signed bootloaders, nothing else.
[14:42] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (jammy-proposed) [2.763]
[14:43] <vorlon> xnox: why is this qemu a separate source package?
[14:43] -queuebot:#ubuntu-release- Unapproved: accepted ldns [source] (impish-proposed) [1.7.1-2ubuntu0.1]
[14:43] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (jammy-proposed) [22.04.12]
[14:43] <juliank> vorlon: this is a EFI shell script that runs at boot and disables ACPI, nothing else
[14:43] <vorlon> ok
[14:44] <juliank> vorlon: Well a service that installs the script :)
[14:44] <vorlon> why a separate source package for that?
[14:44] <xnox> vorlon:  because it is a descriptive name and doesn't have qemu inside it. it manipulates bootnext; manipulates files on BSP; and runs a script of EFI shell. it is meant to be a small package that one can install & remove, to boot with/without acpi, upon package install/removal.
[14:44] <juliank> vorlon: we only need it for autopkgtest-cloud to disable ACPI on the workers for the kernels that need it
[14:44] <vorlon> I'd rather see this as a separate binary package built from qemu than a small Ubuntu-specific source package prone to becoming abandonware
[14:44] <xnox> it is separate source package, to ensure it doesn't entagle with anything; and needs to be used as trigger= for all of adt-matrix tests that are triggered by raspi kernel
[14:45] <vorlon> hmm
[14:45] <juliank> xnox: I thought we'd put this in a PPA and then enable that from autopkgtest/adt-matrix
[14:45] <xnox> i do not want to pull in qemu from proposed, just because a test of raspi kernel is heppening.
[14:45] <juliank> xnox: But I guess britney also runs raspi kernel tests itself?
[14:45] <vorlon> ... there's no reason it would be in -proposed
[14:45] <xnox> juliank:  we run a lot of adt tests with and without PPAs enabled.
[14:46] <juliank> yes, but you could run all of them with a PPA just for this enabled, was my idea
[14:46] <juliank> nobody else needs this?
[14:46] <xnox> vorlon:  the alternative of it being a package; is something that build into src:autopkgtest or like into autopkgtest-cloud; doing it as a package looks like the cleanest integration
[14:46] <xnox> juliank:  majority of our arm kernels do not have acpi enabled.
[14:46] <vorlon> well if it's in autopkgtest-cloud it doesn't require SRUing to multiple series
[14:47] <vorlon> and if it's only used internally to autopkgtest-cloud...
[14:47] <xnox> vorlon:  but needs engineering time of people who can change and deploy changes to autopkgtest-cloud......
[14:47] <vorlon> it certainly sounds less byzantine than our existing autopkgtest-cloud code for launching VMs
[14:47] <xnox> which juergh & xnox are not..... and so far foundations did not resolve this issue.
[14:47] <vorlon> xnox: that is not a less scarce resource than SRU team
[14:48] <xnox> true
[14:48] <juliank> We did not resolve this, because it was not on our agenda, but IS to align firmware
[14:48] <xnox> also our scalingstack cloud is a mess with mixed host os releases; and mixed firmwares; and they failed to align firmwares
[14:48] <vorlon> "did not resolve this issue" - sure, because I don't think it's a priority to test per-hardware kernel flavors in autopkgtest?
[14:48] <xnox> it blocks all sru cycles for years now
[14:48] <xnox> because half of nodes, cannot run and complete linux-raspi tests
[14:49] <juliank> vorlon: it is, because they retry until they get swirlix and block resources
[14:49] <xnox> which we retry ad-infinity until they hit the right node and pass
[14:49] <vorlon> juliank: that sounds like a kernel team bug
[14:49] <xnox> which we developed a fix for
[14:49] <juliank> vorlon: no that's what they do because they want this tested
[14:49] <vorlon> because what does testing on swirlix actually tell you
[14:49] <juliank> vorlon: it boots on swirlix because the firmware is older and always exposes dt
[14:49] <xnox> because is, bootstack, openstack teams fail to make a working cloud.
[14:49] <vorlon> it tells you nothing about whether the package will work on raspi
[14:50] <xnox> vorlon: the tests execute that dkms modules build & work with raspi kernel.
[14:50] <juliank> there's some alignment
[14:50] <vorlon> xnox: is the next package going to be one that makes nodes look like Azure so that kernel has meaningful tests?
[14:50] <juliank> it needs to boot and the modules need to build and load
[14:50] <juliank> :)
[14:50] <juliank> we actually really ought to have one that makes it look like azure cvm
[14:50] <vorlon> no we shouldn't :P
[14:51] <xnox> vorlon:  instead we changed azure kernel config to have modules to boot off virtio drives, cause we have no place to test cvm at all without it.
[14:51] <juliank> well nullboot should have a an autopkgtest for it  :)
[14:51] <xnox> vorlon:  as nobody is giving us secret hyperv or access to upload test images ;-)
[14:51] <vorlon> "& work with raspi kernel" which requires running the kernel.  Having your testing rely on whether the *hardware specific* kernel boots on openstack is inherently flaky
[14:51] <juliank> I agree with the kernel team that this provides valuable input that DKMS modules built and modprobe successfully (?)
[14:52] <xnox> vorlon:  i am open to remove and migrate off qemu-efi-noacpi, as soon as a better solution is available to maintain testing baseline and no go off the rail and not testing things with autopkgtests at all.
[14:52] <vorlon> I agree /that this is a useful thing to ensure/
[14:52] <vorlon> I do not agree that autopkgtest in openstack is the right place to do this
[14:52] <juliank> wrt foreign kernels booting on openstack, meh
[14:52] <juliank> it means the kernel team needs to commit to ensure they are compatible to that extend
[14:52] <juliank> and they do that
[14:52] <xnox> vorlon:  this is how currently it is enforced for all in-archive Ubuntu kernel.s
[14:52] <juliank> * extent
[14:53] <juliank> xnox: So basically we add a new magic trigger qemu-efi-noacpi/0 and then patch autopkgtest to do those changes
[14:54] <xnox> vorlon:  we would happily test these things outside of autopkgtest infrastructure; but at the moment autopkgtests is the only way to get onto scalingstack for this; and block migrating these kernels to updates.
[14:54] <juliank> xnox: can you test that yourself and wrap this in a setup script you can pass to autopkgtest?
[14:54] <xnox> nothing else at the moment exists that catches in-archive -proposed dkms migration & kernels
[14:54] <juliank> then we only need to remove the fake trigger and add a --setup-script command
[14:55] <vorlon> xnox: it didn't block SRU migrations before
[14:55] <xnox> vorlon:  it does today
[14:55] <juliank> setup-command
[14:55] <vorlon> ... because the kernel team has chosen to make it a blocker
[14:55] <xnox> .... because we were told to by release team
[14:55] <juliank> rightfully so
[14:55] <xnox> because this one time kenrel migrated without fixed dkms modules and someone noticed and didn't like it
[14:55] <juliank> we don't want to get another kernel breaking everyone's dkms module
[14:56] <juliank> xnox: "someone"
[14:56] <vorlon> xnox: what do you mean, "By the release team"?
[14:56] <vorlon> who said this?
[14:56] <juliank> xnox: that was when shit was all over the place, including phoronix?
[14:57] <vorlon> I am cross that I have seen no high-level communication about this on any mailing lists
[14:57] <xnox> vorlon:  at the moment all kernels are always blocked via britney hints.
[14:58] <vorlon> I mean, britney hints mean nothing for SRUs currently, but yes
[14:58] <xnox> vorlon:  and bot automaticlaly unblocks each kernel if all migration criteria are satified. which is adt-matrix passing; cert testing passing; regression tests passing; etc.
[14:58] <vorlon> yes
[14:58] <xnox> vorlon:  in $devel it actually blocks migration; and in $stable it blocks humans releasing kernel tracker as well.
[14:58] <vorlon> and previously, adt-matrix absolutely would unblock kernels without requiring them to pass a boot test in a non-representative environment
[14:58] <xnox> at the moment for half of ubuntu kernels on arm, half of arm nodes, fail to pass the adt-matrix tests, which are retried multiple times over.
[14:59] <xnox> because our cloud does not provided consistent VMs across all compute nodes
[14:59] <juliank> IMO long term we should have custom properties, and then kernel tests can mandate custom properties
[14:59] <xnox> and there are no ways to enforce consistent guests unless we do something like the above package does;
[14:59] <juliank> but this works *now*, it's a valid workaround
[15:00] <xnox> or contribute engineering to openstack to generate new instance flavour types with new parameters which we would then be able to deploy and use consistently from autopkgtest-cloud
[15:00] <vorlon> it's a valid workaround to enable something whose fundamental sanity I continue to question
[15:01] <juliank> I don't think we're going to get actual hardware for autopkgtest testing and like MAAS autopkgtest support
[15:03] <juliank> xnox: so i think the script provided is a valid setup-commands script, so we just need to drop it into the autopkgtest-cloud tree and do the magic trigger
[15:04] -queuebot:#ubuntu-release- Unapproved: corosync (focal-proposed/main) [3.0.3-2ubuntu2.1 => 3.0.3-2ubuntu2.2] (i386-whitelist, ubuntu-desktop, ubuntu-server)
[15:06] -queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-gnome (jammy-proposed/main) [42.0.1-1ubuntu1 => 42.0.1-1ubuntu2] (no packageset)
[15:08] <juliank> xnox: https://paste.ubuntu.com/p/ZjPKgn2tNP/
[15:08] <juliank> oops typo at the end
[15:10] <juliank> Need to add apt-get install efibootmgr at the start I suppose
[15:10] <juliank> but otherwise, this should work
[15:10] <juliank> or do we want that in autopkgtest itself so people can do it locally?
[15:10] <juliank> I guess locally people can just pass -no-acpi
[15:11] <juliank> I guess some patching needed to make it exit 0 if not on EFI
[15:12] <juliank> but meh
[15:13] -queuebot:#ubuntu-release- New source: rpiboot (jammy-proposed/primary) [0~20220131+git693d5be-0ubuntu1]
[15:14] <juliank> xnox: We could also pull the script from an external repo and give you all sorts of means really, like we git pull autopkgtest-package-configs
[15:15] <juliank> but if at all, not now :)
[15:19] <xnox> juliank:  yes -no-acpi is the thing that is not a toggle in nova compute guest flavours that we were discussing with juergh to proposed to openstack upstream to support configuring instance types like that.
[15:20] <xnox> juliank:  cause like then we could have (small/medium/large)x[acpi|noacpi] configured in our cloud region; or like just the ones that autopkgtest-cloud uses in its tenant and use those directly.
[15:20] <xnox> it is insane that our cloud provides random instance types under the same name
[15:21] <xnox> juliank:  but also having that thing in the archive would be useful, for people to reproduce stuff within the same VM
[15:21] <juliank> xnox: So I deployed the change now
[15:22] <juliank> xnox: So I guess one should try if that works
[15:23] <juliank> everything cowboy deployed in the past weeks, because duh, need to get charm store login working again
[15:23] <juliank> three people tried to login to the charm store, none succeeded
[15:23] <juliank> $ charm login
[15:24] <juliank> ERROR cannot retrieve the authentication macaroon: unexpected response status from server: 404 NOT FOUND
[15:24] <xnox> fun
[15:24] <xnox> juliank:  that trigger thing is nice; but might actually break adt-matrix if it starts triggering raspi tests with that trigger.
[15:25] <xnox> cause ideally we wanted to achieve these tests without extra visible trigger, but that's still better than nothing at all.
[15:26] <xnox> juliank: is efibootmgr installed on images?
[15:26] <juliank> xnox: I added a line
[15:26] <juliank> xnox: apt-get install -y efibootmgr
[15:27] <xnox> ok , i must be looking at an old pastebin, cool.
[15:27] <juliank> xnox: yeah, here's the commit https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/commit/?id=c8fa2a1fe07788038b0fd2f7e5ca656e76644395
[15:27] <juliank> xnox: we can remove the trigger and look it up in a file in the package-configs repo
[15:27] <juliank> I don't have ACL for that though, needs release team members
[15:28] <juliank> xnox: or we can do it for all non-default arm64 kernels, but that might not be appropriate either
[15:29] <juliank> xnox: But try out that trigger with one package and see if it works, and then we can think more
[15:29] <xnox> ack.
[15:30] <xnox> juliank:  it's very series & kernel flavour dependend. some of these things have unique names per series too
[15:30] <juliank> Then we add a file `noacpi` with one kernel source package trigger per line that should use noacpi
[15:30] <juliank> the files you can write linux-meta-raspi/arm64/jammy or stuff
[15:39] <xnox> juliank:  You submitted an invalid request: qemu-efi-noacpi/0 is not published in jammy
[15:39] <xnox> https://autopkgtest.ubuntu.com/request.cgi/?release=jammy&arch=arm64&package=bbswitch&trigger=linux-meta-raspi%2F<IP_ADDRESS>5.5&trigger=qemu-efi-noacpi/0
[15:39] <juliank> xnox: ah
[15:39] <xnox> am i doing it wrong?
[15:39] <juliank> xnox: one sec
[15:39] <xnox> (as in it's not allowed via request.cgi? or you can fix request.cgi?)
[15:42] <juliank> xnox: on it
[15:43] <juliank> xnox: try now
[15:44] <xnox> it went through
[15:44] <xnox> but now we need to know nova status of that machine run and if it was on a good or bad node.
[15:44] <juliank> xnox: what package?
[15:44] <xnox> cause if it is successful we will not know if the setup script worked or if the node was good one anyway
[15:44] <xnox> juliank:  i did https://autopkgtest.ubuntu.com/request.cgi/?release=jammy&arch=arm64&package=bbswitch&trigger=linux-meta-raspi%2F<IP_ADDRESS>5.5&trigger=qemu-efi-noacpi/0
[15:45] <juliank> xnox: OK, it's queued now, will have to wait until it rusn
[15:52] <xnox> juliank:  it's running host juju-4d1272-prod-proposed-migration-4
[15:53] <juliank> xnox: it's krusha
[15:53] <juliank> oh bad substitution in the script at line 26
[15:54] <juliank> shell_bootnum=$(efibootmgr | grep -E '^Boot[0-9A-F]{4}\*? +EFI Internal Shell$' || true)
[15:54] <juliank> shell_bootnum=${shell_bootnum:4:4}
[15:54] <juliank> so the 2nd line failed
[15:55] <juliank> xnox: ah, hmm it's run by /bin/sh instead of bash
[15:55] <juliank> xnox: can we port that to posix shell?
[15:56] <juliank> silly autopkgtest should just run the file as is
[15:56] <xnox> juergh:  ^
[15:57] <xnox> juliank:  i don't know why kernel team is obsessed with bashism =) i had to fix bashism in a few places already, which was trivial and more portable.
[15:57] <ginggs> vorlon: btw, esys-particle and csound do appear on the python3.10-only tracker, except they are green because they built successfully
[15:57] <xnox> juliank:  make setup script do bash -c "...." ?! =)
[15:57] <juliank> nah it copies over the script content
[15:58] <juliank> or reads the file and then does /bin/sh -c?
[15:58] <juliank> I don't know for sure
[15:58] <juliank> anyway weird
[15:58] <ginggs> vorlon: and fwiw, the csound autopkgtest that fails on s390x was only added recently, so never passed on s390x
[16:02] <juliank> xnox: Can just add `| awk '{print $1}' | tail -c +5` instead of the subst I suppose
[16:03] <juliank> or something
[16:03] <juliank> one can write this nicer
[16:08] <xnox> juliank:  we made a package that we tested; which has autopkgtest; which works ;-)
[16:09] <xnox> juliank:  it might be nicer to accept the package then doing porting into autopkgtest-cloud scriptage
[16:11] <vorlon> seb128: focal and jammy desktop dailies are both oversized; is there work to be done to bring them down?
[16:12] -queuebot:#ubuntu-release- Unapproved: lto-disabled-list (jammy-proposed/main) [23 => 24] (core, i386-whitelist)
[16:12] <vorlon> ginggs: oh right, another thing that makes the transition tracker useless to me ;)
[16:12] <juliank> xnox: meh
[16:13] <vorlon> paride: and ubuntu-server/ppc64el in focal; do we expect this to come back down to size?
[16:15] <vorlon> ginggs: so we should neuter this csound test as XFAIL on s390x?
[16:19] <paride> vorlon, hi, yep I saw the warning but I still have to compare the images to see what got fatter
[16:19] <vorlon> paride: cheers
[16:19] <paride> vorlon, if I conclude it's normal I'll open a MP bumping the size limit
[16:20] <vorlon> juliank: libjpeg8-empty which you uploaded a no-change rebuild for ain't going anywhere, it's trying to take over libjpeg-progs which is built from libjpeg9; do you want to follow through on this?
[16:20] <vorlon> juliank: (visible at the top of https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt)
[16:21] <juliank> I guess drop the package?
[16:22] <juliank> I don#t understand why this happens
[16:22] <juliank> like when libjpeg9 took over libjpeg-progs when libjpeg8-empty still also had it, it's weird
[16:25] <juliank> xnox: so fixed script seems to have worked, stuff ran at boot: https://paste.ubuntu.com/p/frKND8q5WZ/
[16:25] <juliank> xnox: but it ran on swirlix, so need to confirm it helps on other
[16:28] <vorlon> juliank: because they want the binary to be built against the latest version of libjpeg, not the old one?  it's allowed in the archive (both Debian and Ubuntu) for this to happen, but it's the responsibility of the maintainer of the previously-owning package to fix up the source to not build it
[16:28] <vorlon> so yes, drop this binary package
[16:28] <vorlon> (and then we'll have to NBS it out of -proposed)
[16:29] <juliank> ack
[16:29] <juliank> xnox: running on krusha now
[16:33] <xnox> juliank:  krusha host is not known to me.....
[16:33] <xnox> horum.
[16:34] <juliank> xnox: kernel fails to boot with IRQ exception
[16:34] <juliank> xnox: does that ocunt as success?
[16:34] <xnox> is there a full log, and node details?
[16:34] <juliank> xnox: Endless lines of "IRQ Exception at 0x000000009BC11F38"
[16:34] <xnox> juliank:  it should have always booted everywhere
[16:34] <xnox> juergh:  ^^^^
[16:34] <juliank> maybe there was more
[16:34] <xnox> juliank:  but IS never told me that krusha exists, and what that is.
[16:35] <juliank> maybe it's a fixed buffer size in openstack and it ran over
[16:35] -queuebot:#ubuntu-release- Unapproved: udisks2 (jammy-proposed/main) [2.9.4-1build1 => 2.9.4-1ubuntu1] (core, i386-whitelist)
[16:35] <juliank> xnox: ok now it did boot after all
[16:36] <juliank> xnox: Not sure where the IRQ exception happened
[16:36] <juliank> xnox: Like it was before the reset I suppose, so the old kernel did not shut down cleanly or whatever?
[16:36] <juliank> Setting up bbswitch-dkms (0.8-10ubuntu2) ...
[16:36] <juliank> autoinstall for dkms modules has been disabled.
[16:36] <juliank> dpkg: dependency problems prevent removal of dkms:
[16:36] <juliank>  bbswitch-dkms depends on dkms (>= <IP_ADDRESS>).
[16:36] <juliank> I don't understand how this is a pass
[16:36] <juliank> but still
[16:37] <juliank> it seems to work
[16:37] <juliank> At least the kernel booted
[16:37] <juliank> tests passing with failures is not my problem :D
[16:38] <xnox> juliank:  the dkms autopkgtest is weird; it installs the module; then tries to remove dkms; to ensure that the dkms module (directly or indirectly) has dkms specified as a dep.
[16:38] <xnox> such that "dependency prevents removal of dkms" is expected and good
[16:38] <xnox> juliank:  but old kernel is generic kernel and should be working "fine"
[16:39] <juliank> this is also a broken qemu I think
[16:39] <juliank> see cRT##131118
[16:41] <juliank> xnox: So I deployed this to the other cloud worker now, and the trigger should be working now, we can turn this into a file tomorrow if you can build one, in the same format that autopkgtest-package-configs has for the other files
[16:41] <juliank> xnox: but in this case it will apply to the trigger, so if you have
[16:41] <juliank> linux-meta-raspi/arm64/jammy in noacpi, it will do this hack
[16:41] <juliank> and so on
[16:42] <juliank> you can use all in some places, but there's a bug
[16:42] <juliank> You can't use name/all/jammy
[16:42] <juliank> but that should be fine
[16:42] <vorlon> always nice to see a flavor metapackage in the archive that ./update fails on because update.cfg references jammy
[16:43] <juliank> (really ought to fix architecture wildcard + fixed release)
[16:43] <xnox> juliank:  i think it is a success!
[16:43] <juliank> xnox: anyway I think that wraps up my day
[16:44] <xnox> juliank:  thank you.
[16:44] <vorlon> juliank: not following closely, does the above mean the qeme-efi-noacpi package doesn't need accepted?
[16:44] <juliank> vorlon: yes, we now have a fake qeme-efi-noacpi/0 trigger (soon probably a list file of kernel packages rather than trigger)
[16:45] <vorlon> ok
[16:45] <vorlon> (hopefully soon; putting this in the trigger, blech)
[16:46] <juliank> with the package it would have been a trigger as well :)
[16:46] <vorlon> blechblech
[16:55] <xnox> vorlon:  well, not a single person in the world will be able to discover or use the magic qemu-efi-noacpi trigger.
[16:55] <xnox> vorlon:  so strictly it's not needed in the archive, but also not sure how to ensure people know about it.
[16:55] <cjwatson> juliank: charm login> the old charmstore became read-only - you'll need to use charmcraft and upload to charmhub
[16:55] <vorlon> xnox: I'm not worried about accidental usage, I'm bleching at the abuse of the trigger interface for this.  The cleanup juliank describes would make me happy
[16:56] <xnox> =))))))))))))
[16:56] <xnox> i would prefer the file-based-trigger to simply install package from the archive.
[16:56] <vorlon> mm
[16:56] <xnox> rather than do magic out of the blue from built-in source code but that's just me.
[16:56] <xnox> i have no opinion about that either.
[16:57] <xnox> i just fear that this thing will break whenever cloud gets upgrades.
[16:57] <xnox> but should be mostly harmless.
[16:57] <xnox> so like not break anything; but like stop making things happen.
[16:57] <ginggs> vorlon: yes, we could neuter the test, or hint it for now and i'll file a bug in debian
[16:58] <ginggs> would someone please accept lto-disabled-list/24 ?
[16:58] <vorlon> ginggs: given that the package previously had passing autopkgtests on s390x, which improves our quality coverage, my preference is always to neuter the test where feasible and keep it green
[16:58] <vorlon> looking
[16:59] <vorlon> ginggs: gyoto is making me angry btw.  Something somewhere is embedding dpkg-buildflags output into a binary and using that when invoking g++ and then failing, and it's largely inscrutable
[16:59] <juliank> cjwatson: ugh, hopefully that's not a lot of work
[17:00] <juliank> The endless cycle of Migrate to new stuff, new stuff gets deprecated
[17:01] <vorlon> welcome to software engineering? :)
[17:03] <cjwatson> juliank: https://discourse.charmhub.io/t/charmhub-transition-faq/5636 may help
[17:09] <juliank> thanks cjwatson
[17:17] -queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (jammy-proposed/universe) [0.91 => 0.92] (no packageset)
[17:18] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (jammy-proposed) [0.92]
[17:28] -queuebot:#ubuntu-release- New: rejected qemu-efi-noacpi [source] (jammy-proposed) [1.0]
[17:29] <vorlon> ginggs: so, lto-disabled-list; I'm surprised to see additions here as my understanding was this list was meant to be short-term and that further packages should be handled via debian/rules overrides, NOT via additions to this list
[17:30] <vorlon> ginggs: I can accept this now because it's not really all that material, but I'd like to make sure folks get on the same page wrt the correct practice here
[17:30] <vorlon> (cc: doko)
[17:30] <ginggs> i understood packages in universe should be added to lto-disabled-list
[17:31] <vorlon> why would it be different for universe?
[17:31] <ginggs> i imagine to reduce the maintenance burden of keeping the delta
[17:31] -queuebot:#ubuntu-release- Unapproved: accepted lto-disabled-list [source] (jammy-proposed) [24]
[17:32] <ginggs> https://wiki.ubuntu.com/ToolChain/LTO
[17:32] <ginggs> disclaimer, i wrote part of that page :)
[17:33] <vorlon> ginggs: right lol, I was just looking at the history because I had never seen this before and find that you added i
[17:33] <vorlon> t
[17:33] <vorlon> so I don't think it's part of what was communicated on ubuntu-devel
[17:34] <vorlon> if you and doko agree that this is the right thing to do, please communicate this change on ubuntu-devel
[17:34] <vorlon> also please clarify if it is *expected* that universe packages are only handled via lto-disabled-list or if it's optional
[17:36] <Eickmeyer> ginggs: I have questions on that. I have a package (carla) that I disabled the LTO on in d/rules because otherwise the binary crashes. Should this be added to the lto-disabled-list?
[17:36] <vorlon> tjaalton: hi, gonna need some additional documentation here for xf86-input-wacom jumping from upstream 0.39.0 to 1.0.0 post-FF including extensive changes to the debian packaging dir
[17:36] <ginggs> vorlon: ack, i'll discuss with doko about an announcement
[17:37] <vorlon> Eickmeyer: you only need to do one or the other, and see my question above wrt how strongly we want to encourage use of the lto-disabled-list package: )
[17:37] <vorlon> ginggs: ta
[17:37] <Eickmeyer> vorlon: Thanks, good to know. Just wanted to cover my bases.
[17:37] <ginggs> Eickmeyer: carla is an ubuntu-only package, so i wouldn't put it in lto-disabled-list
[17:38] <ginggs> lto-disabled-list is to allow syncs from debian
[17:38] <Eickmeyer> ginggs: Thanks. There have been mentions of getting it in Debian, but so far nobody has done it or been brave enough. :)
[17:44] <tjaalton> vorlon: upstream jumped from 0.40 to 1.0
[17:44] <tjaalton> vorlon: I can file an ffe tomorrow
[18:01] <vorlon> tjaalton: thanks
[18:03] <tjaalton> vorlon: feel free to reject, I'll amend the changelog with the bug#
[18:05] -queuebot:#ubuntu-release- Unapproved: rejected xf86-input-wacom [source] (jammy-proposed) [1:1.0.0-3ubuntu1]
[18:12] <seb128> ginggs, why wouldn't the 'being able to sync from Debian is better' apply to main also? it is weird that the list is restricted to universe
[18:15] <vorlon> doko, ginggs: fyi the lack of an unversioned libgcc-dev (real or virtual) leads to things like intel-mkl hard-coding a test dep on libgcc-8-dev | libgcc-7-dev | libgcc-6-dev...
[18:17] -queuebot:#ubuntu-release- Unapproved: intel-mkl (jammy-proposed/multiverse) [2020.4.304-2ubuntu1 => 2020.4.304-2ubuntu2] (no packageset)
[18:18] -queuebot:#ubuntu-release- Unapproved: accepted intel-mkl [source] (jammy-proposed) [2020.4.304-2ubuntu2]
[18:21] <vorlon> jbicha: wpewebkit has versioned -dev package names (blech) and the reverse-dependencies don't appear to have been updated for this new upstream version you synced from experimental; please follow this through
[18:22] <jbicha> thanks
[18:26] <seb128> I've pinged a few time in the past week about that but could someone review https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1967127 ?
[18:26] <vorlon> seb128: looking
[18:26] <seb128> it has been waiting for more than a week, which makes a difference in testing at this point of the cycle
[18:27] <seb128> also unsure how or where to raise the issue about FFe reviews delays but it's really an issue imho
[18:27] <seb128> vorlon, thanks
[18:28] <vorlon> seb128, jbicha: there are two upstream links provided for "changes" here; the first is a reasonably-compact summary, the second is a git log that I'm not going to attempt to read.  Is there anything that could bite me as a result of *not* reading that?
[18:29] <seb128> vorlon, I've reviewed the commits, though not in details, and I didn't spot anything concerning. Also the new version is in Debian testing now and no issue has been reported if that helps getting some confidence
[18:30]  * vorlon nods
[18:32] <vorlon> cpaelzer: why does LP: #1953363 have an 'in progress' python-xmlschema task and an ubuntu-archive subscription? You appear to have promoted it to main already
[18:32] <seb128> vorlon, thanks
[18:41] <ginggs> seb128: i don't know the reason why lto-disabled-list was originally populated with packages not in main, but i'll try to get clarity and include it in the mail to ubuntu-devel
[18:44] <seb128> thanks
[19:27] <knome> hello! it's super late in the cycle, but we really would like to upload a new wallpaper for xubuntu. i wonder if anybody from the release team could ack that for us, so we could get it uploaded asap. the freeze exception bug is here: https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1967940
[19:29] <knome> bluesabre, ^
[19:30] -queuebot:#ubuntu-release- Unapproved: gudhi (jammy-proposed/universe) [3.5.0+dfsg-1ubuntu1 => 3.5.0+dfsg-1ubuntu2] (no packageset)
[19:31] -queuebot:#ubuntu-release- Unapproved: accepted gudhi [source] (jammy-proposed) [3.5.0+dfsg-1ubuntu2]
[19:52] <knome> stgraber, *cough* ... hello? :)
[20:05] -queuebot:#ubuntu-release- Unapproved: libadwaita-1 (jammy-proposed/main) [1.1.0-1ubuntu1 => 1.1.0-1ubuntu2] (no packageset)
[20:37] <vorlon> jbicha: also, something is wonky with this package because the wpewebkit binaries are not showing up on https://people.canonical.com/~ubuntu-archive/nbs.html, have they done something horrible like continuing to list the packages in debian/control?
[20:38] -queuebot:#ubuntu-release- Unapproved: pacemaker (focal-proposed/main) [2.0.3-3ubuntu4.3 => 2.0.3-3ubuntu4.4] (i386-whitelist, ubuntu-desktop, ubuntu-server)
[20:39] <jbicha> vorlon: webkit is built twice, once for the libsoup2 API and once for the libsoup3 API 😒
[20:39] -queuebot:#ubuntu-release- Unapproved: intel-mkl (jammy-proposed/multiverse) [2020.4.304-2ubuntu2 => 2020.4.304-2ubuntu3] (no packageset)
[20:40] -queuebot:#ubuntu-release- Unapproved: accepted intel-mkl [source] (jammy-proposed) [2020.4.304-2ubuntu3]
[20:40] <vorlon> jbicha: that does not explain to me why https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt correctly identifies libwpewebkit-1.0-dev and libwpewebkit-1.0-3 as not built from the current source package and therefore are candidates for removal, but https://people.canonical.com/~ubuntu-archive/nbs.html does not show this.  That normally only happens if there are errors
[20:40] <vorlon> in debian/control
[20:40] <jbicha> ok, let me read more carefully
[20:41] <vorlon> $ grep Package: debian/control
[20:41] <vorlon> Package: libwpewebkit-1.0-dev
[20:41] <vorlon> Package: libwpewebkit-1.1-dev
[20:41] <vorlon> Package: libwpewebkit-1.0-3
[20:41] <vorlon> Package: libwpewebkit-1.1-0
[20:41] <vorlon> Package: wpewebkit-driver
[20:41] <vorlon> Package: libwpewebkit-1.0-doc
[20:41] <vorlon> yep
[20:41] <vorlon> this is wrong
[20:43] <jbicha> it's very creative packaging
[20:43] <vorlon> well that's a red flag
[20:43] <vorlon> ;)
[20:44] <jbicha> I don't need or want the libsoup3 versions in jammy so I think I ought to just enable the libsoup2 version and simplify the packaging for jammy
[20:45] <jbicha> not sure if the creative stuff is useful for Debian or not
[20:53] -queuebot:#ubuntu-release- Unapproved: wpewebkit (jammy-proposed/universe) [2.36.0-2ubuntu2 => 2.36.0-2ubuntu3] (no packageset)
[20:54] -queuebot:#ubuntu-release- Unapproved: accepted wpewebkit [source] (jammy-proposed) [2.36.0-2ubuntu3]
[21:12] <vorlon> waveform, jawn-smith: rpiboot - how does this relate to "piboot" we've discussed before which is the onboard firmware?  I.e. why do these binary blobs need to be shipped in the Ubuntu archive?
[21:16] <jawn-smith> vorlon: rpiboot isn't a bootloader, but is rather a utility to put compute modules into MSD mode for flashing and configuring secure boot on compatible Pi 4 devices
[21:19] <knome> vorlon, thank you!
[21:19] <vorlon> waveform, jawn-smith: there's a GPL license file in the source but this license is not mentioned in debian/copyright
[21:20] <vorlon> (win32/LICENSE.txt)
[21:24] <waveform> vorlon, that's for the cygwin bits they're shipping in their windows output to get rpiboot working there but none of that ever winds up in the binary packages we produce -- does that still require mentioning in d/copyright?
[21:33] <vorlon> waveform: according to Debian policy it does, because debian/copyright is a description of the rights on the source package, not the binary packages
[21:37] <waveform> right, I'll get on with it
[23:28] -queuebot:#ubuntu-release- New sync: hyperspy (jammy-proposed/primary) [1.6.1-1]


 so around noon we'll get together? @RazPi you on board?
 Where sushi?
 Pembroke?
 Progress quest beast!
 time?
 @Ivoriesablaze, I can be free whenever. @RazPi
 @Ivoriesablaze - let me know when you are up. Also where is this place?
 I'm up
 Where is the electronics place?
 I need to pick something up in Mimai today. Wondering if it is close by
 Milam dairy and 31st
 Any word form @RazPi
 Nope
 Ok call him in a few
 @Ivoriesablaze, Cool.
 I'll*
 I also got a Oculus Go if you guys want to see it later. I am also getting a Lenovo Mirage Google Daydream in a bit
 Of course I want to see it! Lol
 You can see them both. The Lenovo is going to be ready for me to pickup in Miami in a few hours. You can come with me to pick it up if you want
 Nice!
 Strange, straight to voicemail
 He may have forgotten to charge his phone again.
 So what's the plan, then?
 Do you want to try to stop by judge and see if he wants to come?
 Sure
 Okay, leave when you're ready and let me know when you're on the road
 I'm driving right now.
 Ok
 Heading over to @RazPi now
 I need to head to Miami to pick up the daydream headset. We can do it on our way to the shops.
 I was gonna try to hop on a train
 I have to be there by 5
 If you want to take the train, that is fine. I can pick you up
 Okay
 Just be on your way ASAP
 I'm already on the road
 Judd's phone was dead, he'll be ready in about a half hour, I'm just gonna drive
 Ok. Meet me at my house and we will take one car
 Sounds good
 @Ivoriesablaze, Let me know when you are on the road
 In transit
 Ok. Just left?
 Affirmative
 Ok. Let me know when you pass the Ft Lauderdale airport
 Mission complete at alpha site proceeding to bravo
 Comm going dark until checkpoint Charlie
 I'm having issues with internet.  I called Comcast.  Apparently there is an outage at my address specifically and an agent will not be able to help.
 Usually they state there is an issue in my city or neighborhood.  This time they stated there is a outage at my address.
 Squirrel eat through your coax?
 I've had cases where somebody fired a shotgun at the ground and severed lines, because BrightHouse doesn't bury them well
 Last week, LECs tech wouldn't goto a CO to replace a card due to a wild animal loose in the city
 Comcast going to dispatch to resolve?
 I have no idea.
 They should if it's past your demarc
 Yeah
 Which kinda sounds that way
 I'd press them a bit I think. Dunno if residents get any sort of sla or guarantee, but that's no good
 So I got a "free" Fandango movie tocket for donating my blood
 @SivaMachina, I know the oakwood theater does that
 @RazPi  - location?
 I95 and hollywood
 So is there any decent movies put that isn't a superhero film?
 @RazPi, Ok, so close
 @SivaMachina, Ready Player One
 @AdamOutler - want to meet up in Pembroke for sushi. Offer is open to anyone
 We are almost at the buffet


[18:24] <h00k> oho look.
[18:31] <seiflotfy> hey guys
[18:31] <seiflotfy> mhall119: around?
[18:32] <mhall119> seiflotfy: I am
[18:32] <seiflotfy> quick question, is zeitgeist being used in ubuntu phone?
[18:32] <seiflotfy> if yes are you guys using the qml bindings we created
[18:32] <mhall119> seiflotfy: no idea, but it wouldn't surprise me since it's used in Unity
[18:32] <popey> you probably want to use #ubuntu-discuss
[18:32] <mhall119> I don't know about QML bindings
[18:33] <seiflotfy> mhall119: we have qml bindings since over a year now
[18:34] <seiflotfy> mhall119: http://wm161.net/2011/10/28/libqzeitgeist-0-8-0/
[18:34] <mhall119> seiflotfy: cool, I'll pass that along
[18:34] <seiflotfy> :d
[19:03] <boulabiar> Does the phone use wayland ?
[19:35] <RzR> hi
[19:36] <RzR> are there ubuntu4android devels around ?
[19:37] <RzR> pop corns :)
[19:37] <tola> Does anyone know what will be the default browser for Ubuntu for Phones? Will it be Webkit or Gecko based?
[19:37] <WanderingEnder> ok, so. The last thing I heard about this was awhile back. This is not the full stack, not some chrooted... thing.
[19:38] <mhall119> tola: I don't know if that's been decided yet
[19:38] <Aiki> mhall119: I know qt is just a toolkit, but recently canonical has been cutting slices on the base ISO, so i thought it would be smart to switch all the focus to Qt.
[19:38] <RzR> WanderingEnder, yes I played w/ chroot too
[19:38] <FabianS> Most likely webkit.
[19:39] <mhall119> Aiki: even with a focus on Qt, there are a lot of Gnome components in Ubuntu that aren't going away anytime soon
[19:39] <WanderingEnder> I have a RAZR, original version (Droid, obviouzly), I'm wondering if I could put this on it.
[19:39] <RzR> but I was wondering if there are public stuff to test out ?
[19:39] <WanderingEnder> When ther eare reference builds available.
[19:39] <tola> mhall119: What about the app runtime? Jono seems to think that will be Webkit, does anyone know otherwise?
[19:39] <Muphrid> what will be the language for the SDK? QML?
[19:39] <user82> when will the images be available for testing..does anyone know?
[19:39] <mhall119> tola: for HTML5 apps?
[19:39] <Aiki> mhall119: IC Pitty... :( Thanks though!
[19:39] <tola> mhall119: yes
[19:39] <RzR> cordova ?
[19:40] <mhall119> tola: again, I don't know, but Webkit wouldn't surprise me
[19:40] <mhall119> Muphrid: QML is going to be the recommended one
[19:40] <mhall119> but AFAIK it'll be open to others
[19:40] <Muphrid> mhall119: alright, thanks
[19:41] <tvoss> mhall119, ping
[19:41] <tola> mhall119: It would be a shame to miss out on all the new APIs being added to Gecko http://wiki.mozilla.org/WebAPI
[19:41] <mhall119> tvoss: pong
[19:42] <tola> mhall119: But maybe that's an incentive to add an implementation of those APIs to Webkit...
[19:42] <mhall119> tola: any API worth developing for should be as cross-platform as possible
[19:43] <tola> mhall119: Like the new Ubuntu application environment you mean?
[19:43] <tola> mhall119: (I agree, I'm just being sarcastic)
[19:43] <WanderingEnder> Also, honest question.
[19:44] <WanderingEnder> How badly are US carriers going to be able to gut Ubuntu.
[19:44] <mhall119> WanderingEnder: that's a business thing, I don't think anyone here can answer that
[19:44] <mhall119> ideally they wouldn't want to change it at all
[19:45] <WanderingEnder> Yeah, but look at Verizon.
[19:45] <WanderingEnder> Also, the overview page says you'll need an Atom or Quad Core A9 for desktop convergence.
[19:45] <mhall119> WanderingEnder: as a Verizon customer, I know exactly what you mean :)
[19:45] <WanderingEnder> I thought we were able to get away with dual core 1GHz for that.
[19:46] <tola> btw, the reason I was asking about the web app runtime is that I've worked on some web apps that would be cool to port to Ubuntu for phones. They use the new Web APIs in Gecko, and one of them is a browser app (hence my other question) https://github.com/mozilla-b2g/gaia
[19:46] <mhall119> WanderingEnder: that I don't know about, I remember the UfA requirements originally said dual-core ARM
[19:46] <Chelsea> So, after doing reading for the last hour straight on this subject, just to be clear on this whole matter, there is no product (just software and ecosystem). Just like the Ubuntu-TV, right?
[19:47] <mhall119> Chelsea: correct, this isn't something you can go get right now
[19:47] <WanderingEnder> This is just high level for OEMs and operators. http://www.ubuntu.com/devices/phone/operators-and-oems
[19:47] <mhall119> for Canonical, the softwre is the product, but there is no hardware
[19:47] <WanderingEnder> (Both to my statement of Quad Core and to 'where do I get this thing?')
[19:49] <tola> Where's the source code btw?
[19:49] <Chelsea> mhall119, I really don't think a big "announcement" is the way to go if they're just looking for oems. This was old news allready. Some ppl's expectations where higher.
[19:49] <mhall119> tola: the components and toolkit are here: https://launchpad.net/~ui-toolkit/+archive/ppa
[19:50] <mhall119> instructiosn for instaling them are on http://developer.ubuntu.com/get-started/gomobile/
[19:50] <WanderingEnder> I'm not really seeing anything new, actually, than the old announcement that just looked like "Motorola WebKit Native."
[19:50] <gotwig> hey there
[19:50] <WanderingEnder> Except that the requirements for desktop have doubled.
[19:50] <Muphrid> rewriting my other question in the other channel: If I make an ubuntu customization (say a derivative) on the phone and make an image of it, is it possible to boot this new image on another phone? this is basically asking if the bootloader is locked
[19:50] <gotwig> what about scopes and lenses for ubuntu for phones? I dont see a point about that here http://developer.ubuntu.com/get-started/gomobile/
[19:50] <mhall119> gotwig: there shouldn't be anything different for lenses/scopes on the phone interface
[19:51] <gotwig> mhall119, but how does the stuff show up :X
[19:51] <mhall119> gotwig: same way it does on the desktop
[19:51] <gotwig> mhall119, what is with the right click?
[19:51] <WanderingEnder> Muphrid, that's between you, your device manufacturer, and your carrier.
[19:51] <mhall119> gotwig: I don't know how previews will work, if that's what you mean
[19:52] <gotwig> mhall119, yeah ^^
[19:52] <WanderingEnder> I own a Verizon phone with a locked boot carrier, by Motorola. I expect hell to freeze over before Verizon acknoledges US law requiring interoperability.
[19:52] <tola> mhall119: Is that just for developing QML apps?
[19:52] <mhall119> gotwig: see the image at the top of http://www.jonobacon.org/2013/01/02/announcing-ubuntu-for-phones/ ?  Those are lenses on the phone
[19:52] <mhall119> tola: "that" being what?
[19:52]  * RzR http://rzr.online.fr/q/ubuntu# is #UbuntuPhone open ? I plan to adapt it for !N950Club which already support !Ubuntu #Chroot (watch video)
[19:52] <Muphrid> WanderingEnder: right, so it will be like android, the manufacturer decides
[19:52] <FabianS> Buing phones in the USA seems like a huge pain to me.
[19:52] <mhall119> FabianS: it is
[19:53] <WanderingEnder> Muphrid, its a cell phone. The carrier will always decide, and the manufacturer will obey.
[19:53] <FabianS> With several non-compatible networks and stuff like that.
[19:53] <FabianS> At least all the other countries agreed on one standard.
[19:53] <WanderingEnder> Canonical understands that, look at the OEMs and Carriers page.
[19:53] <Muphrid> true
[19:53] <Muphrid> heh
[19:53] <tola> mhall119: Sorry, the "components and toolkit" you can download, do they only enable QML-based apps to be run?
[19:53] <WanderingEnder> Noting how you can develop your carrier specific bloatware easily.
[19:53] <mhall119> FabianS: except S. Korea, I think, who also uses CDMA
[19:53] <gotwig> hide for the launcher on  the phone.. something i miss on my desktop
[19:53] <mhall119> tola: yes, those are the QML components
[19:54] <FabianS> mhall119: Do they have only CDMA or both CDMA and GSM?
[19:54] <mhall119> FabianS: probably both, like the USA
[19:54] <mhall119> you know, just to make it more difficult
[19:54] <Muphrid> WanderingEnder: Can you link the page?
[19:55] <WanderingEnder> http://www.ubuntu.com/devices/phone/operators-and-oems
[19:55] <Muphrid> thanks
[19:55] <FabianS> Here the only real stupid thing is the choice of LTE frequencies.
[19:55] <FabianS> But that's mainly apple's fault.
[19:55] <WanderingEnder> Carrier Exclusivity and Custom Capabilities.
[19:56] <FabianS> All other phone companies managed to put LTE chips in their phones that support more than two frequencies.
[19:57] <WanderingEnder> I mean, basically, in the US, if you don't play ball with the carriers, the manufacturers will not use your OS, cause they carriers won't carry that phone.
[19:57] <WanderingEnder> So, Canonical will guess how high when Verizon says jump.
[19:58] <mhall119> WanderingEnder: more likely there will be an OEM between
[20:00] <WanderingEnder> I guess I'm wondering how badly carriers and OEMs will rip this apart.
[20:02] <jaduncan> WanderingEnder: see Android.
[20:02] <FabianS> But they hardly touched iOS and WP.
[20:10] <mhall119> http://developer.ubuntu.com/get-started/gomobile/ is up and running again
[20:10] <tvoss> mhall119, \o/
[20:25] <sivang> hi all
[20:40] <mhall119> hi sivang
[20:40] <sivang> hey mhall119
[20:40] <sivang> is this the channel that helped produce this: http://www.ubuntu.com/devices/phone/operators-and-oems ?
[20:41] <mhall119> sivang: this is a public discussion channel for the phone project
[20:41] <sivang> mhall119: excellent
[20:41] <mhall119> sivang: do you have questions about that page?
[20:42] <sivang> mhall119: first of all, I think that's the best attempt at biting at the apple (but I may be a bit biased being ubuntu universe develoepr for quite some time and uploader to main through sponsorship in ancient times)
[20:42] <mhall119> I'm a bit biased myself, so that's okay :)
[20:42] <sivang> mhall119: I would be anxious to try this phone, not sure I could afford it money wise, but would be dying to try it.
[20:43] <sivang> mhall119: I was with the community team pre-mataro, if that tells you something..
[20:43] <sivang> mhall119: and used to email with the sabdfl occasionally ;)
[20:43] <ubuntubhoy> sivang: images will be released for the Galaxy nexus soon
[20:43] <sivang> amazing
[20:43] <ubuntubhoy> not the most expensive handset anymore
[20:43] <mhall119> ^^ that
[20:44] <Walther>  So, nice work on the Ubuntu phone, when will it be available for download?
[20:44]  * sivang wonders who around here still recalls Mataro besides kdub
[20:44] <mhall119> though I can forsee a run on those phones on ebay and craigslist once those images are out :)
[20:44] <k1l_> so there will be an image for the nexus4, too? or do the devs still wait for google to deliver their device? :)
[20:44] <mhall119> Walther: I don't have a solid time frame on those images yet
[20:44] <mhall119> k1l_: I've only heard that there will be images for the galaxy nexus
[20:44] <sivang> mhall119: what's the way to contribute and get noticed for Ubuntu phone?
[20:45]  * mhall119 doesn't recall Mataro
[20:45] <k1l_> mhall119: ok
[20:45] <Walther> Also, how much of it will be open source / closed source?
[20:45] <sivang> mhall119: 2004, after Warty Warthog
[20:45] <mhall119> sivang: currently we have the UI toolkit available for people to get started making/porting apps
[20:45] <Walther> Will it be possible to contribute in near-official or truly official ports to other "open" devices, namely, Nokia N9 and the like?
[20:45] <mhall119> Walther: as much as possible will be open source
[20:45] <sivang> mhall119: ah, so it is not an open source project...
[20:46] <sivang> mhall119: https://wiki.ubuntu.com/MataroConference
[20:46] <mhall119> sivang: the images are not available yet
[20:46] <ubuntubhoy> sivang: can't be fully open sourced - vendors and OEM's need an amount of control over devices
[20:46] <ubuntubhoy> or they won't buy into it
[20:46] <mhall119> but from what jono and rick spencer were saying on the OMG stream earlier, it should all be available under an open license
[20:47] <mhall119> with the probable exception of hardware drivers
[20:47] <sivang> ubuntubhoy: mer is open source and you can contribute there , and sailfish will be apparently, so I guess there's a way?
[20:47] <mhall119> though even most of that should, thanks to Google and Android, be open
[20:47] <mhall119> it will ultimately depend on the hardware used though
[20:48] <FabianS> Sailfish isn't FOSS.
[20:48] <FabianS> Only the core, not the UI.
[20:48] <ubuntubhoy> mhall119: even on Android OEM's like to lock down bootloaders
[20:48] <FabianS> The Swipe UI nokia made for Meego on the N9 is closed to.
[20:48] <sivang> FabianS: but to contribute that's all you care..
[20:48] <mhall119> ubuntubhoy: well bootloaders are an entirely different matter
[20:49] <mhall119> an OEM can lock a bootloader running 100% open software
[20:49] <ubuntubhoy> but they are still linked
[20:49] <sivang> mhall119: is it using lybhybris?
[20:49] <mhall119> ubuntubhoy: I mean that what the OEM does with the bootloader won't have any bearing on the openness of our software's development
[20:50] <mhall119> sivang: I don't know
[20:50] <sivang> *libhybris
[20:50] <ubuntubhoy> mhall119: I get that - it's just another factor to consider is all
[20:51] <sivang> so it is developed not in th eopen so far..
[20:51] <ubuntubhoy> well, nothing has been released yet
[20:51] <ubuntubhoy> so can't really say yet
[20:52] <mhall119> sivang: it was developed internally up until now
[20:53] <sivang> mhall119: I see, with voluteers as well?
[20:53] <Walther> Also, just an interested thought - will there be parts of Ubuntu Phone project merged to the Ubuntu Tablet project?
[20:53] <mhall119> sivang: what do yu mean?
[20:53] <Walther> The UI demo seemed much more sleek than the recent videos of Ubuntu Nexus 7 project
[20:54] <Walther> and the same UI ideas could perform well on the tablet as well
[20:54] <Walther> swipe, gestures, speech recognition HUD, etc
[20:54] <sivang> mhall119: well, before warty warthog released, there was a community team as well that was per-invited to join the fun before the release :)
[20:54] <ubuntubhoy> The N7 project is still only about getting the core OS working
[20:54] <ubuntubhoy> no UI stuff being done
[20:54] <mhall119> Walther: all form factors will eventually share the same foundation
[20:54] <ubuntubhoy> at least in public
[20:54] <sivang> mhall119: as you can see, I'm highly keen on community matters
[20:55] <mhall119> sivang: me too :)
[20:55] <sivang> mhall119: observer ;) http://comments.gmane.org/gmane.linux.ubuntu.doc/70
[20:55] <sivang> mhall119: notice the dates..
[20:55] <mhall119> sivang: there was some non-canonical folks contributing via skunkworks
[20:55] <sivang> I'm in old timer, too old a even.
[20:55] <Walther> BTW, am I getting the right impression that mhall119 is a developer working for canonical? Any other actual employees stating ~"official" opinions here?
[20:55] <sivang> mhall119: ah it has a name today? what is skunkworks?
[20:57] <mhall119> Walther: former-developer, I'm on the community team now
[20:57] <mhall119> I wasn't involved in the development of the phone
[20:57] <sivang> lately, I'm feeling addicted to mobile os development
[20:58] <mhall119> sivang: skunkworks is a program to bring in community people to contribute to all kinds of internal projects prior to their official announcement
[20:58] <spjt> So has anyone finished a fart app yet
[20:58] <mhall119> sivang: http://mhall119.com/2012/11/welcome-to-the-skunk-works/
[20:58] <Walther> And yeah, repeating my previous (important) question - will it be possible to contribute to official and/or non-official ports to other devices, or preferably, not ports but actual "device support"?
[20:58] <mhall119> spjt: not yet, it's yours for the taking
[20:58] <sivang> mhall119: just read it, so mark named it after 10 years :)
[20:59] <Walther> It would be awesome to be able to flash my N9 with Ubuntu, and have it run the same exact OS build that a nexus 4 with Ubuntu would
[20:59] <mhall119> sivang: perhaps it was a re-initialization
[20:59] <Walther> (separate ports are always a headache, no proper updates etc)
[21:01] <ubuntubhoy> mhall119: quick question, when the GNex UOS images become available will they be announcing it or will they just 'be there' without a fanfare ?
[21:01] <spjt> I'm getting 404 errors when installing the QML toolkit preview (second command)
[21:01] <mhall119> ubuntubhoy: I'm sure it'll be announced and picked up by all the usual media
[21:01] <ubuntubhoy> K
[21:02] <ubuntubhoy> was just wondering after the N7 image went live prior to its announced release time
[21:03] <spjt> Is there an emulator image?
[21:07] <mhall119> spjt: emulator for phone hardware?
[21:08] <spjt> mhall119: I'd think it would use the Android emulator.
[21:08] <Walther> Are there *any* images available yet?
[21:09] <mhall119> Walther: not yet, only the app development components
[21:09] <Walther> that's what i thought.
[21:09] <spjt> Has anyone else gotten the QML toolkit installed?
[21:09] <pmcgowan> spjt: we can do that, use the android emulator, will keep you posted, we have played with that a bit
[21:11] <ubuntubhoy> The Android emulator works pretty well now
[21:11] <FabianS> It's really slow though.
[21:11] <ubuntubhoy> no where near as bad as it was
[21:11] <spjt> There must be some way to emulate it, otherwise there'd be no way to know if anything works at all
[21:12] <mhall119> spjt: it'll probably run on the desktop, but yes it does make it hard to test certain things
[21:12] <spjt> W: Failed to fetch http://ppa.launchpad.net/ui-toolkit/ppa/ubuntu/dists/precise/main/source/Sources  404  Not Found
[21:12] <spjt> mhall119: I mean the actual phone OS itself, not the apps
[21:13] <rsalveti> it's not hard to emulate it, specially as have qemu working nicely with the android sdk
[21:13] <mhall119> spjt: /w 51
[21:13] <mhall119> blah, ignore that
[21:14] <spjt> Ot
[21:14] <spjt> I only want the emulator to play around with it, so it's not too big of a deal..
[21:14] <pmcgowan> mhall119: I dont think the source packages have been published, but the ui is qml anyway
[21:15] <pmcgowan> the toolkit I mean
[21:15] <spjt> I'm more interested in finding out why I can't install the toolkit.
[21:16] <popey> spjt: I just tried here, and it works okay
[21:16] <Gaggo> hooray
[21:16] <mhall119> spjt: what error are you getting?
[21:16] <leonardo> omg
[21:17] <spjt> I don't get any errors with add-apt-repository ppa:ui-toolkit/ppa. apt-get update gives me W: Failed to fetch http://ppa.launchpad.net/ui-toolkit/ppa/ubuntu/dists/precise/main/source/Sources  404  Not Found
[21:17] <mhall119> spjt: ah, packages are only there for Quantal atm
[21:18] <sivang> there's an issue signing to the wiki
[21:18] <spjt> mhall119: ok then...
[21:18] <sivang> I'm using my lp creds
[21:19] <ubuntubhoy> installing fine here
[21:19] <Mercury> mhall119: Is the base X, wayland, or something else entirely?
[21:19]  * sivang feels the SSO is surprised to see me back
[21:19] <mhall119> Mercury: I'm not entirely sure
[21:20] <mhall119> sivang: you can't expect to be gone for so long and have it just immediately welcome you back into it's life
[21:20] <sivang> mhall119: LOLs
[21:20] <mhall119> bring flowers or something
[21:20] <sivang> granted
[21:20] <sivang> mhall119: I'm getting too old
[21:20] <FabianS> Some german news site says that Ubuntu phone uses Android drivers.
[21:21] <FabianS> Any confirmation on this?
[21:21] <popey> our own site says that
[21:21] <sivang> FabianS: this is mentioned on the releas web pages
[21:21] <popey> http://www.ubuntu.com/devices/phone
[21:21] <mhall119> The nexus 7 images do too
[21:21] <FabianS> Wonder how they do that.
[21:21] <popey> "Ubuntu runs well on entry-level smartphones – yet it uses the same drivers as Android"
[21:21] <k1l_> FabianS: in the video mark mentions that it will work with android kernels and android drivers
[21:21] <mhall119> IIRC, the drivers have been submitted to the upstream kernel already, but haven't landed in it yet
[21:21] <sivang> FabianS: read carefully :) hence why I was asking if it was using libhybris https://github.com/stskeeps/libhybris
[21:22] <Mercury> FabianS: Ubuntu is compatable with a typical Android Board Support Package (BSP).
[21:22] <sivang> FabianS: but having applied to work for Linaro, I know that the linaro.org project did that natively.
[21:22] <sivang> FabianS: gathering vendors from all overs, literally
[21:22] <sivang> FabianS: and creating a cool common core to run ubuntu on and devices
[21:22] <sivang> :)
[21:22] <sivang> mhall119: I have some control over the material, mind you ;)
[21:22] <HumanBeing> I asked this before, but I didn't get an answer: What's about the developement of Ubuntu for Android? Is it dead?
[21:23] <popey> HumanBeing: no
[21:23] <Mercury> FabianS: I read that as 'we can run natively an an Android kernel', possibly with the extra library pieces normally used for the camera, cell radio, etc.
[21:23] <sivang> mhall119: flowers not needed, but a kiss on the chick could help ;)
[21:23] <HumanBeing> popey Great, thanks
[21:24] <popey> ʘ‿ಠ
[21:24] <mhall119> HumanBeing: Ubuntu for Android was pretty much stock Ubuntu with some custom Android work, IIRC
[21:24] <sivang> popey: you I remember from ancient times
[21:24] <mhall119> sivang: you calling popey ancient?
[21:24] <ubuntubhoy> you saying he's not ?
[21:25] <mhall119> mind you, I'm happy whenever I talk to someone who makes me feel younger, rather than older
[21:25] <sivang> mhall119: haha
[21:25] <sivang> mhall119: he's been with Ubuntu for a *while*
[21:25] <mhall119> I know
[21:25] <sivang> 'wiki says no'
[21:25]  * sivang retries
[21:26] <sivang> mhall119: it uses debs right?
[21:26] <mhall119> sivang: ubuntu?
[21:26] <HumanBeing> and I've got another question... are there any news about the NexPhone (www.nexcrea.com). In my eyes this would be a perfect piece of hardware for the Ubuntu for phones
[21:26] <mhall119> HumanBeing: I stopped paying attention when they didn't guarantee any work was actually going to be done for the money
[21:27] <spjt> I want the ubuntu phone on the Galaxy Note II. I love the pen.
[21:27] <sivang> mhall119: thje phone version ;)
[21:28] <mhall119> sivang: I don't think it's that far along yet, but debs would be the obvious way for it to go
[21:28] <sivang> finally got a hello from wiki!
[21:28] <popey> sivang: I'm not _that_ old!
[21:28] <sivang> mhall119: hmm, I mean, what's the pkging system there?
[21:28] <sivang> popey: :)
[21:28] <popey> well, maybe I am.
[21:28] <sivang> popey: do you recall me?
[21:30] <mhall119> sivang: I assume it has apt/dpkg on the phone image
[21:30] <HumanBeing> mhall119 oh, ok I always wondered why they haven't got a donate-button on their webpage, which would be necessary if they really have the aim to produce the phone. strange...
[21:30] <sivang> mhall119: okay, thanks.
[21:30] <Mercury> mhall119: I'd be incrediable disappointed if they _didn't_ keep the full packaging system.
[21:30] <mhall119> HumanBeing: they did a kickstarter or one of those crowd-sourcing things
[21:31] <FabianS> That NexPhone looks an awful lot like bloatware.
[21:31] <FabianS> With no real hardware or software visible and really ugly renders.
[21:33] <HumanBeing> mhall119 I know ;) but they haven't got a single link to this on their site
[21:34] <mhall119> HumanBeing: I don't think they reached their goal
[21:35] <HumanBeing> FabianS You're right, but I was interested in this, because they promised that the phone would run Ubuntu
[21:35] <HumanBeing> thx for your information :)
[21:35] <FabianS> Er. I shouldn't write two things at once.
[21:36] <FabianS> *vaporware
[21:36] <FabianS> not bloatware
[21:40]  * sivang wonders if sladen still with Canonical
[21:49] <mhall119> if anybody has questions that don't get answered here, please post them to AskUbuntu using the 'mobile' tag: http://askubuntu.com/questions/tagged/mobile
[21:54] <HumanBeing> A question I found on engadget.com: "If i play fruit ninja or similar game, how this menu sistem going to behave (no phaysical buttons if i understand)??"
[21:58] <popey> HumanBeing: there's a difference between swiping on the screen and swiping in from the edge. We need to be clever about telling the difference.
[21:59] <FabianS> Worked fine on Nokias N9 and N950.
[22:00] <HumanBeing> FabianS: How could you approve that? o.O
[22:00] <FabianS> Approve what?
[22:02] <HumanBeing> that it ran on the N9 and N950
[22:02] <FabianS> ER.
[22:02] <FabianS> Nokia invented those swipe gestures Ubuntu Phone uses.
[22:03] <FabianS> And they worked fine on N9 and N950.
[22:04] <FabianS> https://twitter.com/gregkh/status/286592231731785729
[22:06] <bobweaver> where is the code ?
[22:06] <popey> not available yet
[22:06] <FabianS> s/yet//g
[22:07] <FabianS> probably
[22:07] <popey> now now
[22:07] <bobweaver> popey,  what is framework ?
[22:08] <HumanBeing> FabianS: I see. I'm still not sure, wheather it'll be practical...
[22:08] <bobweaver> I hear that mark was talking about qml
[22:08] <popey> bobweaver: see http://developer.ubuntu.com/get-started/gomobile/
[22:08] <FabianS> HumanBeing: I love the N9's UI. I'm sure the UI will be the least problem with Buntu Phone.
[22:08] <FabianS> Performance looks like more of an issue.
[22:08] <bobweaver> I want to add the form-factor to tv and tablet on my desktop
[22:09] <bobweaver> OMG it is OML !!!!!!!!!!!!!!!
[22:09] <bobweaver> s|oml|qml
[22:09] <bobweaver> Why am I not working on this ?
[22:10] <popey> ☺
[22:10] <bobweaver> popey,  I dont need to learn qml I am a expert in it. But I need to know something that I can import
[22:11] <bobweaver> like import unityphone 1.0
[22:11] <bobweaver> and it it uses qconf ?
[22:11] <bobweaver> if it *
[22:11] <bobweaver> so I can export things like this ......... pasteing
[22:13] <HumanBeing> I don't understand why they used QT instead of gtk
[22:13] <bobweaver> http://paste.ubuntu.com/1490045/
[22:14] <bobweaver> because qt is awesome and can use gtk
[22:14] <bobweaver> popey,  in that paste I am calling  com.canonical.unity-greeter  so that in any qml file I can do say
[22:15] <bobweaver> lightDmConfiguration.background == "/usr/share/backgrounds/wahtever.png"  that will change the glib
[22:16] <bobweaver> popey,  so You see before I write any apps for Phone I would like to see backend (QT) stuff to see what options there are to play with
[22:17] <bobweaver> like why import qconf and all that jazz if bckend of phone has it already ?
[22:17] <popey> bobweaver: i may be the wrong person to ask these types of questions
[22:17] <bobweaver> popey,  maybe you can ppoint out the right person ?
[22:17] <popey> mhall119 might, but he's just gone off the clock
[22:18] <bobweaver> dang ..... :)
[22:19]  * bobweaver thinks that this is one of the best moves that Canonival has ever made. Qml is the future I have been ranting about that for like 1.5 years
[22:20] <sivang> bobweaver++
[22:20] <popey> \o/ we got bobweaver on a happy day :D
[22:20] <bobweaver> lol
[22:20] <sivang> bobweaver: me for a bit over 2 years
[22:20] <sivang> ;)
[22:20] <sivang> but I'm biased from the Qt project side :-p
[22:20] <bobweaver> sivang,  you are also qml dev ?
[22:21] <bobweaver> sivang,  maybe you have seen some of the work that I have done ?
[22:23] <sivang> bobweaver: not sure, perhaps
[22:24] <sivang> bobweaver: been doing mostly closed stuff unfortunaltey, and private stuff
[22:24] <bobweaver> sivang,  I will make a video of what I am working on right now
[22:24] <bobweaver> kinda cool
[22:24] <sivang> bobweaver: sure thing, should be good to see
[22:25] <ubuntubhoy> Be careful - he will ask you to come look at his puppies next.
[22:25]  * lpotter knows people that have been ranting about qml for 5 years
[22:29] <bobweaver> ubuntubhoy, lets see your qml code :)
[22:29] <bobweaver> I am going to make it so that the dash is render types are vars for easing.type : Easing.Whatever
[22:30] <sivang> lpotter: but you you, with Jolla no? :)
[22:30]  * sivang grins
[22:30] <lpotter> i do have a current contract with jolla.
[22:31] <sivang> lpotter: twitter said something, a while ago :)
[22:31] <lpotter> but also a maintainer in qt-project
[22:31] <bobweaver> http://www.youtube.com/watch?v=B8BCLEAH-oc
[22:31] <FabianS> I really really hope that jolla will get their hands on some decent hardware.
[22:32] <FabianS> But they probably can't compete with nokia in that regard.
[22:33] <FabianS> N9/Lumia800 and 920 are the best made smartphones I have ever seen.
[22:33] <bobweaver> jolla is cool is that what the phone is based off of  ?
[22:34] <FabianS> ?
[22:34] <FabianS> Jolla is the successor of Meego and most of the company are former Nokia guys.
[22:34] <lpotter> jolla's sailfish is mer/nemo which is based on meego
[22:34] <FabianS> Well, Sailfish is the successor.
[22:34] <FabianS> Jolla is the company
[22:35] <ubuntubhoy> bobweaver: I would show you, but you could hurt yourself by laughing too much
[22:35] <ubuntubhoy> sadly I am no dev
[22:35] <ubuntubhoy> just a little old end user
[22:35] <bobweaver> that is cool ubuntubhoy  want to see my puppys ?
[22:35] <FabianS> lpotter: Are there any informations about who is going to build jolla's hardware?
[22:35] <ubuntubhoy> bobweaver: sure, but I better get a shag out of this
[22:35] <bobweaver> lol
[22:36] <lpotter> FabianS: nothing yet
[22:36] <bobweaver> does any one have any clue at all when the phone code will be released ?
[22:36] <FabianS> :/
[22:37] <FabianS> I would get a N9 if it was <200€
[22:37] <FabianS> But with such old hardware it isn't worth ~280€.
[22:38] <ubuntubhoy> bobweaver: everywhere just says 'soon'
[22:38] <ubuntubhoy> they were quick with the N7 code though
[22:39] <ubuntubhoy> and depending how you look at it, before or after CES is logical
[22:39] <ubuntubhoy> before to peek interest
[22:39] <ubuntubhoy> after to talk to vendors/OEM's first
[22:40] <bobweaver> They should give me access if they want some bad code to be wrote j/k I am a good qml dev
[22:40] <user82> but android apps in ubuntu phone are not planned?
[22:40] <popey> user82: unlikely
[22:41] <ubuntubhoy> the question is how hard to port ?
[22:41] <bobweaver> not that hard with things like qt-exporter
[22:41] <popey> no, i think the question is "can I run android apps directly on ubuntu phone"
[22:41] <ubuntubhoy> BB have made fantastic tools for porting android apps to BB10
[22:41] <ubuntubhoy> popey: I mean the follow up after your answer
[22:42] <ubuntubhoy> not the original question
[22:42] <bobweaver> that is the cool thing about qml it is super super easy to work with and there are fast things like xmllistModel that are faster then webapps I would say
[22:43] <bobweaver> There are some bugs that I still can not get around like QWebView crashes because of stupid gtk
[22:43] <bobweaver> like in my tv menu that querys my backend tv server
[22:46] <bobweaver> http://imagebin.org/241468  << everything works great till flash comes into play. and yes I have pluginsEnabled but crash's saying that gtk 2 and gtk 3 can not be used together
[22:46] <bobweaver> webkit is gtk3 and some stuff in unity 2d is still gtk2 like panel. hence crash's
[22:47] <bobweaver> but I can watch big buck bunny and other things that are webm :/
[22:49] <bobweaver> If you or anyone would like to play with or use stuff that I have made there is a ppa for 12.04 But one should only try virtual I would say
[22:49] <bobweaver> https://launchpad.net/~u2t/+archive/bleedingedge
[22:51] <sivang> bobweaver: XmlListModel a true workhorse in 5 I htink it supports JSON
[22:51] <bobweaver> sivang,  that is awesome . Got to love Models
[22:52] <bobweaver> sivang,  that is my new years resolution is to port unity 2d to qt5
[22:52] <bobweaver> have to re-write all the backend stuff though as no qx11info in qt5
[22:54] <sivang> I see.
[22:54] <bobweaver> yeah there is all the Window and WindowInfo plugin stuff that is heavy on the qx11info stuff
[22:55] <k1l_> since the hardware requirements for the high end ubuntu phone mention a quadcore phone. the dev phone for the entry phne is the galaxy nexus, is the nexus 4 the high end phone (besides its not matching the sdcart/emmc space)
[22:56] <bobweaver> I am just happy that canonical is doing something with qt-quick I was real real real sad when things went all 3d
[22:57] <ubuntubhoy> k1l_: The N4 is a high end phone, the GNex, not so much.
[22:59] <jrtappers> What makes a phone not a tablet, cause they need different UI's but there is grey area
[22:59] <k1l_> ubuntubhoy: i know, i got one here :) i just wanted to know if the n4 is a devphone for the high-class version. since its powerfull and delivers all drivers etc.
[23:00] <ubuntubhoy> They have only said they will be releasing GNex images soon iirc
[23:00] <ubuntubhoy> gues that's what they are dev'ing on
[23:01] <k1l_> or if its a motorola one, which got that webtop stuff included, which was used for the ubuntu4android on the atrix
[23:01] <ubuntubhoy> jrtappers: hard one, the N7 (defo a tablet) has a phone UI
[23:01] <jrtappers> What if the user decides? Thats what windows 8 should have done
[23:02] <jrtappers> Let  the user decide, give options, don't tke them
[23:02] <ubuntubhoy> well for what its worth I run a custom ROM on my N7 so that I can have tablet UI
[23:02] <ubuntubhoy> but I think the N10 also uses the phone UI
[23:02] <ubuntubhoy> think the tablet UI has been done away with
[23:03] <ubuntubhoy> so, UI does not define the device
[23:05] <bobweaver> jrtappers,  I would say that it is all about interfaces and buttons
[23:05] <reindeernix> I hope that the phone version won't use Compiz >_>
[23:05] <bobweaver> +1million
[23:05] <popey> It uses.. Beryl!
[23:06] <popey> ;)
[23:06] <sivang> night all, this announcement was a day maker
[23:06] <bobweaver> Easing.whatever is awesome
[23:06] <reindeernix> LOL
[23:06] <bobweaver> popey,  dont scare people like that
[23:07] <sivang> bobweaver: hat's how you take almost close to stock QML lines and make a new app for yourslef: https://github.com/sivang/myrss
[23:07] <sivang> anyway, bad time in UTC+2 world
[23:07] <sivang> night!
[23:07] <jrtappers> bobweaver, I think thats a good answer
[23:08] <bobweaver> jrtappers,  think about people do use mouses with tablets and also need differebt drag points for MouseArea
[23:09] <bobweaver> OnClicked :if (unity2dConfigueration.formFactor  [23:12] <jrtappers> Mice should not be over integrated for risk of becoming necessary
[23:13] <bobweaver> jrtappers,  MouseArea{} elenent is no just for Mouses
[23:13] <jrtappers> No i meant in software design
[23:13] <bobweaver> Oh +1
[23:14] <jrtappers> If mice become necessary then tablets become a lot less small
[23:14] <bobweaver> jrtappers,  there is a good example of why one would want to have different things in AbstractButton.qml  in Unity 2d
[23:15] <ubuntubhoy> A mouse should only be an option for a tablet
[23:15] <bobweaver> esp drag axis and what not for like the dash and the launcher
[23:15] <bobweaver> ubuntubhoy,  correct but if a person plugs one in it def should work
[23:15] <ubuntubhoy> yes
[23:15] <ubuntubhoy> defo
[23:15] <jrtappers> Unity would be god on tablets, but terminal may be slow
[23:15] <bobweaver> that is the thing alot of the best Qml devs are poor and can not afford things that are needed for testing
[23:16] <jrtappers> *good
[23:16] <jrtappers> What about some kind of Aspect Ratio Simulator?
[23:16] <ubuntubhoy> jrtappers: Unity menu is decent, but window management is shit
[23:16] <bobweaver> ubuntubhoy,  blame bamf
[23:16] <ubuntubhoy> The N7 build should have maximus by default
[23:17] <ubuntubhoy> like the old netbook remix used to
[23:17] <ubuntubhoy> plus linux treats touch like a mouse
[23:17] <ubuntubhoy> too precise
[23:18] <jrtappers> Multitouch could lead to opptunities
[23:18] <jrtappers> Like workplace switcher with pinches
[23:18] <ubuntubhoy> yeah
[23:18] <ubuntubhoy> still very early days
[23:19] <bobweaver> libutouch is awesome but always needs more work I would say
[23:19] <bobweaver> for tablet and what not I just have different launcher's loading
[23:20] <bobweaver> like for tablet it is like mac ipad because I am a horrible designer lol
[23:20] <bobweaver> http://paste.ubuntu.com/1490169/  << easy stuff to do if you know the vars/functions/whatever  that Unity has
[23:22] <bobweaver> Of course one can add tests to glib shemea files and then set options
[23:24] <bobweaver> rectangle {id: button ;width: parent.width / 4 ; height: parent.width / 4}MouseArea{anchors{fill: button}onClicked: launcher2dConfigueration.launcherStyle [23:30] <jrtappers> Ubuntu phone should be able to sync over wifi without cloud
[23:39] <reindeernix> jrtappers: Isn't that what you call cloud? >_>
[23:39] <reindeernix> jrtappers: Or do you mean like sending a settings file over wifi or something?
[23:39] <jrtappers> No, as in over wifi, not over internet
[23:39] <jrtappers> For people who have VERY slow internet
[23:40] <jrtappers> ubuntu phone needs personal hotspot
[23:41] <FabianS> Yeah. Tethering is a must.