[07:31] <lag> Does anyone know when Mesa will reach v19.1 in Ubuntu?
[07:35] <seb128> lag, tjaalton would know
[07:36] <lag> seb128: Thanks Sebastien
[07:36] <seb128> np
[07:36] <tjaalton> maybe today
[07:39] <lag> tjaalton: That would be awesome - thanks
[07:39] <lag> tjaalton: Will just propagate to AArch64 pretty quickly too?
[07:39] <lag> s/just/that/
[07:40] <tjaalton> the holdup was a regression in libgles2 which would've needed libglvnd to provide the pkgconfig file for it, but it hasn't been merged yet there.. so I've reverted the regression in mesa instead
[07:40] <tjaalton> and now there's 19.1.2 too
[07:41] <lag> tjaalton: I just need the changes landed in 19.1, but anything above that would be grand
[07:42] <tjaalton> all archs will build the same, so it should be useable from proposed at least by tomorrow
[07:49] <enyc> LocutusOfBorg: so, where d these packages waitinangi for an archive-admin go?
[07:49] <enyc> not the same as bionic-proposed ?
[08:03] <ginggs> enyc: they go here: https://launchpad.net/ubuntu/bionic/+queue?queue_state=1
[08:04] <LocutusOfBorg> enyc, we can read you yes
[08:04] <LocutusOfBorg> enyc, I uploaded the packages in my ppa and in unapproved queue
[08:04] <LocutusOfBorg> you can test packages in my ppa *now*
[08:04] <LocutusOfBorg> the packages in unapproved queue will be accepted and then go automatically in bionic-proposed
[08:05] <ginggs> assuming they are accepted :)
[08:05] <LocutusOfBorg> after somebody verifies the fixes, no regressions are opened and a week or two, they will migrate in bionic-updates
[08:05] <LocutusOfBorg> lol true story!
[08:05] <LocutusOfBorg> e.g. 5.2.30 should be rejected because I already uploaded 5.2.32
[08:06] <lag> tjaalton: Which versions of Ubuntu will see the update to 19.1.x?
[08:10] <tjaalton> lag: 19.10
[08:10] <tjaalton> will actually get 19.2.x
[08:10] <lag> tjaalton: Works for me, thanks
[09:08] <enyc> LocutusOfBorg: hrm talking of virtualbox... maybe this should be improved by next LTS rather than in bionic-updates but... :-
[09:08] <enyc> LocutusOfBorg: the packaging, including -ext-pack  provides no warning/help/support/etc  for  adding users to vboxusers  group for usb passthrough support
[09:17] <enyc> LocutusOfBorg: i really theink eithre default permissions should be changed t not erquire this group,  or  [BOTH a warning about the fact that user is not in vboxusersgroup  should occur with usb passthrough  AND  some facility to add users to vboxusers group should be provided]
[09:32] <LocutusOfBorg> I agree
[09:37] <ginggs> LocutusOfBorg: maybe have a look how wireshark does it
[09:38] <LocutusOfBorg> problem is: should new users being automatically added to it?
[09:39] <LocutusOfBorg> they all work for current users
[09:40] <LocutusOfBorg> anyway yes, adding current user might already be nice
[10:21] <enyc> LocutusOfBorg: i would figrnst question what this permission system is doing and what it is protecting against
[10:21] <enyc> LocutusOfBorg: i guess some kind of raw access to all usb devices  sort of thing
[10:31] <LocutusOfBorg> enyc, ls /dev/vboxusb/ -l
[10:31] <LocutusOfBorg> created via udev with ./src/VBox/Installer/linux/VBoxCreateUSBNode.sh
[10:32] <LocutusOfBorg> bridging usb devices into an internal vm might be a security issue?
[10:32] <LocutusOfBorg> e.g. what if the server has an external usb-attached hdd and some user is using it to steal data?
[10:32] <LocutusOfBorg> I mean, for example for shared servers
[10:43] <Unit193> Ah, looks like LP is finally catching up on Debian uploads.
[10:46] <LocutusOfBorg> Unit193, you beat me for 3 minutes (exo)
[10:46] <LocutusOfBorg> but I syncd apparmor-profiles-extra
[10:48] <Unit193> exo is one of our packages, I'm of course keeping an eye on it (since I'm involved in Xubuntu as well as pkg-xfce.)
[10:49] <Unit193> thunar is the one I've been waiting on..
[10:54] <cjwatson> Yeah, I broke it for a bit, sorry
[10:54] <Unit193> Well thanks for fixing it too. :)
[11:38] <GunnarHj> wgrant: I'd like to call your attention to this request for a new language:
[11:38] <GunnarHj> https://answers.launchpad.net/launchpad/+question/682131
[11:38] <GunnarHj> Looks straightforward to me. 'Everything' is in place - team, locale in glibc, etc.
[11:41] <wgrant> GunnarHj: Looking
[11:46] <wgrant> GunnarHj: I've added the language and added the team to ubuntu-translators.
[11:47] <GunnarHj> wgrant: Excellent, thanks! (The latter I would have access to, I think.)
[11:47] <wgrant> Yep
[11:57] <GunnarHj> wgrant: A detail: What's the reason for including the country code, i.e. "mjw_IN" instead of just "mjw"?
[11:58] <wgrant> True, probably no need to split it.
[11:59] <wgrant> GunnarHj: Fixed.
[12:00] <GunnarHj> wgrant: Good; think that's better. Then if someone would create a mjw_BD locale, for instance, they can share translations.
[12:27] <enyc> LocutusOfBorg: so far VirtualBox in PPA test, can't find anything working worse than 5.2.18 -- but 5.2.32 is indeed working with 5.0.0-20 kernel from LinuxMint 19.1
[12:28] <LocutusOfBorg> enyc, host and guest?
[12:28] <LocutusOfBorg> both virtualbox and virtualbox-hwe?
[12:28] <LocutusOfBorg> also guest-additions?
[12:28] <enyc> LocutusOfBorg: host, intel 64bit  linuxmint 19.1  (largely ubuntu 18.04.x),  virtualbox,  +ext-pack + guest-additions   all insatll and work
[12:29] <enyc> LocutusOfBorg: guest -- pile of Windows  machines in this case,  guest additions install fine
[12:31] <enyc> LocutusOfBorg: did not find a sepaarate -hwe virtualbox package  except guest addiions for ilnux which isn't my usage case
[12:58] <rbasak> Is it safe to cast an int * to a bool * in general?
[12:59] <rbasak> (specifically an stdbool.h bool, ie. a _Bool)
[12:59] <rbasak> I'm patching something for the MySQL transition that uses std::vector<my_bool> to manage an array so that can point to individual elements
[13:00] <rbasak> But now that my_bool is a bool, std::vector<bool> is specialised and uses bitfields, so we can't get pointers to them.
[13:00] <rbasak> If I use std::vector<int> instead then I get pointer conversion errors since the MySQL API does require bool pointers.
[13:01] <rbasak> Save for massive refactoring I don't see how I can fix this without some kind of pointer compatibility between a bool * and some other data type.
[13:02] <rbasak> Or, any way to get around the standard std::vector<bool> specialisation? A typedef maybe?
[13:02]  * rbasak tries _Bool directly
[13:08] <rbasak> _Bool didn't work
[13:08] <rbasak> The compiler still uses thd std::vector<bool> specialisation in that case AFAICT
[13:15] <jamespage> doko: any chance you could process a few RM's for us - specifically:
[13:15] <jamespage> https://bugs.launchpad.net/ubuntu/+source/glare/+bug/1836143
[13:15] <jamespage> https://bugs.launchpad.net/ubuntu/+source/python-ceilometerclient/+bug/1836142
[13:15] <jamespage> https://bugs.launchpad.net/ubuntu/+source/openstack-resource-agents/+bug/1836623
[13:15] <jamespage> as we're unpicking python 2 from the openstack package set, would be better to clean that lot out rather than have to spend cycles on refreshing them
[13:16] <jamespage> thanks :)
[13:18] <coreycb> doko: here's the full list of RM bugs for us: https://paste.ubuntu.com/p/bDMPrkpysX/
[13:30] <rbasak> Wrapping the bool inside a struct and making an std::vector of that seems to have worked.
[13:42] <ricotz> hi, is there any progress in fixing https://launchpad.net/ubuntu/+source/systemd/240-6ubuntu10 ?
[13:43] <seb128> ricotz, I think Balint is out today/tomorrow but maybe bdmurray or vorlon know of the status?
[13:48] <ricotz> seb128, hi, I see
[15:00] <vorlon> seb128, ricotz: no, this wasn't on my radar yet (due to the extent of the backlog of foundations packages stuck in -proposed that we're working through).  I expect it'll be on rbalint's plate on Monday
[15:01] <seb128> thx vorlon
[15:02] <seb128> ricotz, was it any specific problem created by that upload/the fact that it doesn't build (out of blocking the fix described to reach eoan)?
[15:30] <ricotz> seb128, sorry, no specific problem here, other than it is non-installable here for quite a while, and systemd is not just some random package ;)
[15:31] <seb128> ricotz, do you enable eoan-proposed? you shouldn't :)
[15:31] <ogra> waveform, do you know if agherzan plans to fix ram allocation ? it would really be nice if we could use the full 4GB on a 4GB pi4 (his u-boot only inits 1GB, using my kernel directly from config.txt gets me the full range of RAM)
[15:32] <waveform> ogra, good question - I've yet to even get it successfully booting on a pi4 (though I'm not using his patch directly - tried combining it with our current u-boot version, but evidently we need a later base)
[15:32] <ricotz> seb128, I guess a few people should, I came across some packaging oversights in the past ;)
[15:32] <waveform> ogra, I would assume so though as that's one of the major benefits of the 4 so it's rather incomplete without it
[15:33] <ogra> yeah, that will be a pain, i'D got with a fresh checkout of the base (luckily i'm a bit more free with my core developer images not being official :) )
[15:33] <ogra> *i'd go ..
[15:34] <ogra> your alternative would be to put a giant patch on top of our base and then put the pi4 stuff on top
[15:34] <ogra> iirc the deb sources are really old
[15:36] <waveform> u-boot in eoan has been bumped to 2019.04 so not *that* old (that's the version I attempted to bung the patches on - got a successful build that'd also boot a pi3 happily, but not the 4)
[15:36] <waveform> still, the patches are on master so we may need to bump u-boot further to 2019.07 (which is going to be my next attempt) - and yes, it's a huge patch so it's pretty ugly but if it's all one patch it should be easy enough to drop when support officially makes it upstream
[15:38] <ogra> well, u-boot is relatively safe to go with the very latest usually ...
[15:39] <ogra> (i always use the latest when i start with a new gadget snap for a new board, typically thats even an improvement )
[15:39] <waveform> indeed - and given we're already at 2019.04 for eoan it wouldn't be a huge leap to 2019.07
[15:39] <ogra> yeah
[15:40] <ogra> and we're at a point in the cycle where bumping it should still be okayish
[15:41] <rbasak> ddstreet: nice job with the bind9 deadlock!
[16:14] <ogra> waveform, btw, do you know if omxplayer should already be able to play 4k (i just updated my omxplayer-pi snap today (i'm building from the popcornmix tree) and seem to not be able to play anything bigger than 1080p)
[16:14] <ogra> the console on the pi4 seems to come up fine in 4k though (the font is so small, its nearly unreadable (
[16:15] <waveform> ogra, what's the format of the file? If it's h264 then no: the h264 decoder block in the GPU is the same as on the vc4 so it's limited to 1080p60
[16:15] <waveform> ogra, that said I don't know if omxplayer has been updated to handle the h265 block yet
[16:16] <ogra> ah, no, it were all h264 trailers i tested ...
[16:16] <ogra> (4k ones though)
[16:16] <waveform> ogra, ah - apparently omxplayer doesn't support h265 yet: https://www.raspberrypi.org/forums/viewtopic.php?p=1484297#p1484297
[16:16] <ogra> ah, thanks a lot !
[16:16] <waveform> kodi's the only (current) means of playing 4k on the 4
[17:46] <ahasenack> hi, is bileto out of comission for eoan?
[17:47] <ahasenack> all I get is "all tests passed", and when clicking on the report, it says all tests are running and have always failed
[18:31] <bdmurray> seb128: Should I have any snaps installed immediately after installing and rebooting eoan?
[20:04] <santa_> rbalint: hi. I have seen you made the last systemd upload, thanks for your work. I have found an issue with it:
[20:04] <santa_> executing this produces a hang: "systemctl start network-online.target"
[20:05] <santa_> this doesn't happen with the previous package version
[20:07] <santa_> and that "systemctl start network-online.target" is important imho, because it's used by the autopkgtest LXD backend after rebooting testbeds
[20:10] <ahasenack> you can start a target? I didn't know that
[20:10] <ahasenack> what does it do?
[20:10] <santa_> btw it hangs with the machine already up and the network already up, not sure what would happen in other conditions
[20:11] <santa_> ahasenack: I don't know much about systemd, but I guess it would start the network
[20:11] <santa_> or exit inmediately if it's already up
[20:44] <seb128> bdmurray, better to check with #snappy for details but the initial setup takes a while, we had issues with that in disco and the initial setup, it can easily take a few minutes for them to be ready (and there is also an issue with the 5.2 kernel, but it shouldn't impact the initial install since it requires more snap to be installed to trigger from what I understood)
[20:45] <bdmurray> seb128: well its been a while and still no snaps
[20:47] <seb128> kenvandine, ^ do you know if they are currently known issue with snap missing on new eoan installs?
[20:47] <kenvandine> that means the seeded failed
[20:47] <kenvandine> or is hung
[20:48] <kenvandine> bdmurray: which image was it?
[20:49] <kenvandine> i think that might only be fixed in the pending image
[20:49] <kenvandine> the current might be broken
[20:53] <bdmurray> kenvandine: I downloaded the current from today
[20:54] <kenvandine> current, not pending right?
[20:54] <kenvandine> i think current is from Monday
[20:54] <bdmurray> that's correct
[20:54] <kenvandine> which has a broken seed
[20:58] <tjaalton> lag: sorry, no 19.1.2 this week
[21:38] <gQuigs> am I doing something wrong or does systemd not build in Eoan?  - https://launchpad.net/~bryanquigley/+archive/ubuntu/1796501/+packages
[21:38] <gQuigs> 322/514 test-json                               FAIL     0.22 s (killed by signal 11 SIGSEGV
[22:15] <vorlon> gQuigs: https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190614-gcc9-eoan.html#foundations-bugs and https://launchpad.net/ubuntu/+source/systemd
[22:20] <gQuigs> cool, so it's not just me, ty
[22:22] <gQuigs> although the first amd64 build.. got lucky? - as arm64 failed with my same error..