Re: Legality of using free VMware Workstation Player for alpha and beta testing of Ubuntu?
Thanks, that's what I needed to know! Virt-manager is more than sufficient for my needs, and I can always cough up the $150-$200 if I really want to do VMware testing. Thank you for your time and help! On Fri, May 13, 2022 at 3:51 AM Shane O'Sullivan wrote: > It's a breach of the EULA. I would highly recommend installing > virt-manager as a suitable alternative. > > On Fri 13 May 2022, 08:17 Aaron Rainbolt, wrote: > >> I am digging deep into the world of Ubuntu development and am trying to >> make sure my alpha and beta testing is as effective as possible. I also >> don't want to cash out an arm and a leg for expensive software to do so. >> I've been using virt-manager (QEMU/KVM) for testing on virtual machines, >> and while things seem to be going well, I'd like to test on other >> hypervisors too for the sake of catching as many bugs as possible. >> >> VMware provides their Workstation Player product for free, *for >> non-commercial use.* Problem is, I can't figure out if using VMware for >> Ubuntu testing would be considered commercial use. One one hand, I'm not a >> Canonical employee, nor am I using VMware for employment purposes, so that >> would be non-commercial, but on the other hand, I'm helping a large >> enterprise build an OS that is used for commercial purposes, so that seems >> like commercial use. >> >> Do any of y'all do QA testing in the free version of VMware Workstation >> Player? Does anyone know if this is a legal use of VMware? >> >> Thank you for your help and time. >> >> (Note: I *think* these kinds of questions are what this mailing list is >> for, but if I'm misguided and should have sent this to >> ubuntu-devel-discuss, please let me know and I'll direct these kinds of >> questions there instead.) >> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [ubuntu/kinetic-proposed] bluez 5.64-0ubuntu2 (Accepted)
On Fri, May 13, 2022 at 10:39:54PM +0200, Sebastien Bacher wrote: > Hey Brian, > > I noticed that upload and I'm curious about the motivation. It's really > early in the cycle and we will get bluez updates and time for archive > rebuilds later on so I guess the aim is not to get packages built with a new > LTO by release time. Did we have a buggy LTO version in the archive and are > we rebuilding things with a fixed version? Which packages do need a rebuild > and do we need to organize the rebuilds with the owning teams? > > Cheers, > Sebastien Bacher > > Le 13/05/2022 à 21:56, Brian Murray a écrit : > > bluez (5.64-0ubuntu2) kinetic; urgency=medium > > > >* No change rebuild to pickup a new version of LTO. > > > > Date: Fri, 13 May 2022 12:36:19 -0700 > > Changed-By: Brian Murray > > Maintainer: Ubuntu Bluetooth team > > https://launchpad.net/ubuntu/+source/bluez/5.64-0ubuntu2 Hi Seb, Brian uploaded this at my behest. If you were to build with LTO against /usr/lib/x86_64-linux-gnu/bluetooth/plugins/sixaxis.a, which can be found in libbluetooth-dev, then you would see an error like: fatal error: bytecode stream in file ‘/tmp/tmphqmwfhcw/archive-1/sixaxis_la-sixaxis.o’ generated with LTO version 11.2 instead of the expected 11.3 I did some work last week detecting cases like this and requesting rebuilds. My view on this was that if we built these proactively, we might prevent some FTBFS. So not so much a buggy LTO as a mismatched one. Real-world example of this sort of problem, when attempting to build gyoto against liblorene-dev: https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/g/gyoto/20220503_215822_37721@/log.gz lto1: fatal error: bytecode stream in file ‘/usr/lib/x86_64-linux-gnu/lorene/Lib/liblorene_g.a’ generated with LTO version 11.2 instead of the expected 11.3 -Dan -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: autopkgtest missed regression for kinetic
On Fri, May 13, 2022 at 08:05:20PM +0200, Julian Andres Klode wrote: > On Fri, May 13, 2022 at 12:06:46PM -0400, Jeremy Bicha wrote: > > Hi, > > > > I am concerned that the excuses page is ignoring that webkit2gtk > > 2.36.1-1 caused an autopkgtest regression for devhelp. > > > > https://autopkgtest.ubuntu.com/packages/d/devhelp/kinetic/amd64 > > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html > > > > The regression was correctly caught in Debian: > > https://tracker.debian.org/pkg/webkit2gtk > > > > I am concerned because I would expect other packages could have > > introduced regressions but been allowed in to Kinetic. > > It seems the state of the 2 autopkgtest-web workers is inconsistent, > not all results were copied up on all instances. > > I noticed that it retried a migration-reference/0 test after the failure > which indicated it did not allow the failure, but a later run might have > hit the different backend and hence might have a different view. > > So it's unclear if that's the reason, but bdmurray is cleaning that up > right now. The cleanup finished overnight and now both instances of the autopkgtest-web servers have the same information. -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
