[01:12] <Caguax> I am deploying juju on my maas server. I am having an issue with DNS. When I bootstrap the server that is getting bootstrap is getting the ip of the maas server as DNS. I will like to specify The DNS. Any one knows how to do this ?
[01:16] <bigjools> Caguax: edit the dhcp template
[01:25] <bigjools> Caguax: did you see myanswer?
[01:26] <Caguax> bigjools: what populates  'dns_server'  on the dhcp.template option domain-name-servers {{dhcp_subnet['dns_servers']}};
[01:26] <bigjools> Caguax: just remove everything from {{ to }} and put your desired IP in
[01:27] <bigjools> normally the region calculates the value depending on your region's external facing IP
[01:28] <Caguax> bigjools: ok, I think that would do the trick, but should named be running ?
[01:28] <bigjools> Caguax: if you installed maas-dns, it starts it up
[01:28] <bigjools> if you're using an external DNS service, you don't need that
[01:28] <Caguax> bigjools: I think I did install maas-dns...any way I can verify ?
[01:29] <bigjools> dpkg -l maas-dns
[01:29] <Caguax> bigjools: I ran apt-get install maas-dns and it return 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[01:29] <bigjools> it's installed
[01:30] <bigjools> it's not hurting anything
[01:34] <Caguax> I thought that when I choose to manage an interface and use dhcp+dns, the maas server will be use as a relay. I am just trying to understand why is not working when I use manage interface w/ dhcp+dns and the dns server ip that is hand off is the maas server ip
[01:34] <bigjools> what is not working, exactly?
[01:35] <bigjools> and which version of maas are you using?
[01:40] <Caguax> When I deploy a node the ip that it uses for dns is the maas server. And the node can't resolve names. I am using the latest from trusty
[01:41] <bigjools> it should work fine if you set dhcp+dns management on the cluster interface
[01:41] <bigjools> ummm
[01:41] <bigjools> can you check the zone file and see if it's correct
[01:41] <Caguax> Yep that what I thought...but I am missing something :(
[01:41] <bigjools> it should have a CNAME in it for the node
[01:48] <Caguax> it does..let be try to bootstrap juju and try again
[01:48] <Caguax> zone.cisco.com:luflores-juju IN CNAME 10-122-229-113
[03:15] <Caguax> bigjools: you still there ?
[03:23] <bigjools> Caguax: yeah
[03:31] <Caguax> bigjools: The is that I am getting ServFail, this tcpdump...http://paste.openstack.org/show/85464/
[03:33] <bigjools> that's pretty unintelligible
[03:33] <Caguax> bigjools: My maas server is <IP_ADDRESS> and the upstream DNS is <IP_ADDRESS>...It looks like it gets response but it is not pass to the node <IP_ADDRESS>
[03:33] <bigjools> how are you querying the dns server?
[03:34] <Caguax> I ssh to the node (<IP_ADDRESS>) and do a nslookup www.cisco.com
[03:37] <bigjools> did you set the forwarders on the maas dns server?
[03:38] <Caguax> Yes, 'Upstream DNS used to resolved domain not managed by this MAAS'
[03:39] <Caguax> and it looks it use it, base on the tcpdump
[03:40] <bigjools> ok
[03:41] <bigjools> ummm, not sure what's up then, the dns server is configured ok
[03:41] <bigjools> doesn't seem like a maas problem per-se
[03:41] <bigjools> can you do the same lookup from the <IP_ADDRESS> host itself?
[03:47] <Caguax> Yes, on the MAAS server it work fine
[03:47] <bigjools> so you may have a firewall problem?
[03:47] <Caguax> https://gist.github.com/luflores/eae5459783c3914be010
[03:47] <bigjools> can you do any local lookups on the node?
[03:48] <Caguax> MAAS and Node are on the same lan, no FWs
[03:49] <bigjools> I have the same set up here and it all works ok so I'm not sure how I can help :(
[03:49] <bigjools> can you look up the node's own DNS from itself?
[03:51] <Caguax> on the node nslookup to localhost fails too...here how it looks
[03:51] <Caguax> https://gist.github.com/luflores/decfdb9a6d05262e1099
[03:54] <Caguax> bigjools: Thanks for all the help so far....it is kinda later here...I am going to sleep this one off and cont. tomorrow
[03:54] <Caguax> thanks gain
[03:55] <bigjools> Caguax: ok np
[03:55] <bigjools> Caguax: wait - the node is looking up on localhost?
[03:55] <bigjools> ah
[03:55] <bigjools> Caguax: can you do "nslookup luflores-juju" on luflores-juju
[03:56] <Caguax> That fails too :(
[03:56] <bigjools> there's your problem then
[03:56] <bigjools> there must be some firewalling or something else getting in the way, replies are not getting back to your node
[03:57] <Caguax> Let me think about it....and troubleshoot it a bit more
[03:58] <Caguax> I'll connect later tomorrow now post my findings
[03:58] <bigjools> ok.  I am UTC+10 so I won't be around early, assuming you're a Californian :)
[04:00] <Caguax> I am US East Coast :)
[04:00] <Caguax> so bit late here
[04:01] <bigjools> oh, well, yes it is late then
[04:01] <Caguax> good night :)
[04:01] <bigjools> night
[07:14] <rvba> bigjools: I was wondering where the error message "Static IP Address with this Ip already exists." was coming from… but now I realized it a message generate by Django because the field 'ip' on StaticIPAddress is unique…
[07:15] <rvba> it's*
[07:15] <bigjools> rvba: yes I guessed it was a Django message from the weird capitalisation
[07:15] <rvba> Yep :)
[07:15] <bigjools> hence my questions to Andreas
[07:22] <rvba> bigjools: https://code.launchpad.net/~rvb/maas/fix-cap-static-ip/+merge/225606
[07:24] <bigjools> rvba: approved with remark :)
[07:24] <rvba> bigjools: yeah, I hesitated to make it just 'IP'.  But it doesn't seem right to me.
[07:25] <bigjools> rvba: it seems perfect to me
[07:25] <rvba> IP = the protocol
[07:25] <bigjools> it's the field verbose name
[07:25] <rvba> IP address = … the IP address
[07:26] <bigjools> not the works of Shakespeare
[07:26] <bigjools> ;)
[07:26] <rvba> heh
[07:26] <rvba> Well, okay…  I don't care so much as long as it's properly capitalized.
[09:08] <rvba> jtv: gmb: I found other spurious test failures but they happen infrequently: maybe you'll see what's wrong by looking at the stacktrace: http://paste.ubuntu.com/7745766/ and http://paste.ubuntu.com/7741493/
[09:08]  * gmb looks
[09:09] <gmb> rvba: That looks like an isolation problem at first glance.
[09:09] <gmb> But I don’t know OTTOMH why it’s happening.
[09:10] <rvba> gmb: that would explain why I can't seem to recreate the problems when I run just the failing test.
[09:10] <gmb> Yeah.
[09:11] <rvba> On the other hand, the entire DB should be wiped out between tests.
[09:15] <gmb> Indeed.
[09:45] <bigjools> right test case being used?
[09:47] <gmb> jtv: I’ve updated https://code.launchpad.net/~gmb/maas/fix-guess_server_address/+merge/225164, if you have the time or brain power.
[09:49] <rvba> bigjools: yes, it's using APITestCase which derives from MAASServerTestCase.
[11:03] <gmb> rvba: Are you still investigating that isolation weirdness?
[11:03] <gmb> Any luck?
[11:04] <rvba> gmb: no, I want to test my DNS thingy first.  (I've been running the test in isolation for hours and it didn't fail so it *really* looks like an isolation problem)
[11:05] <gmb> rvba: I’m r-o-u-f -ing the test module, but still nothing.
[11:06]  * gmb switches to r-o-u-f -ing maasserver.tests
[11:06] <rvba> I'll go back to r-o-u-f -ing make test
[11:11]  * gmb lunch
[11:12] <gmb> Might as well since this is just loop-de-looping
[11:36] <bigjools> rvba, gmb, allenap, jtv: how are things looking for a beta of 1.6 on Monay?
[11:36] <bigjools> Monday.  /me whacks D key
[11:37] <rvba> allenap: what about the problem Andreas had?  The one about having to re-download all the images?
[11:37] <jtv> bigjools: I can hold the branch I've got ready, and land it after.
[11:38] <jtv> (It's not ready for production until the follow-up branches land.)
[11:38] <bigjools> jtv: ok
[11:38] <bigjools> jtv: I will cut a new release branch anyway
[11:39] <rvba> bigjools: I think we need to do a bit more upgrade testing (I'm doing part of this QA right now) to be confident the release is going to be solid.  But I guess that's probably okay for a beta release.  What do you say?
[11:39] <bigjools> rvba: yes
[11:39] <bigjools> that's the intention of a beta
[11:39] <bigjools> I need to know in more detail what happened to boot resources between 1.5 and 1.6
[11:40] <rvba> I agree.  Hence my question to allenap who was looking into it (I think).
[11:43] <allenap> rvba: I’ve not been able to figure out why that might have happened during upgrade. Nothing in the code or packaging looks likely to have done it, but I’ll try to recreate it this afternoon.
[11:43] <rvba> allenap: cool, thanks.
[11:43] <allenap> rvba, bigjools: It’s not nice, but I don’t think it’s a blocker.
[11:44] <bigjools> what happened apart from moving the config out?
[11:44] <bigjools> anything?
[11:45] <rvba> When Andreas upgraded he apparently "lost" all the alread-downloaded images.
[11:45] <rvba> already*
[11:45] <bigjools> no I mean in the coe
[11:45] <bigjools> code
[11:45] <bigjools> dammit D key
[11:45] <allenap> bigjools: An extra layer was added to the directory hierarchy for boot resources apparently.
[11:45] <bigjools> oh - OS?
[11:46] <bigjools> and no migration script was written I suppose
[11:46] <allenap> I’m trying to figure that out.
[11:47] <bigjools> ok thanks allenap
[12:11] <rvba> allenap: I just upgraded from 1.5.1 to 1.6 (I'm testing something related to DNS) and I "lost" my images too.
[12:18] <rvba> allenap: when I hit "import boot images", I got all the images reported *instantly*… which seems to indicate the images can be found where they are, it's just a matter of forcing a report or something.
[12:22] <allenap> rvba: That’s good, and makes sense. Now, what do we do about that for 1.6? Can we prompt MAAS to do a report from the command-line, and thus the postinst?
[12:22] <rvba> allenap: something doesn't make sense to me: why are the existing images (in the DB) wiped out during upgrade?
[12:25] <allenap> rvba: My guess is that the importer needs to run again to create the new directory structure... which would mean we have to run the importer (not just the reporter).
[12:27] <rvba> allenap: hang on, I forgot something: to speed things up I have a script that keeps a copy of the bootresource dir and restores it each time I install a new MAAS package.  I guess this means I didn't really test what a real user would experiment.
[12:28] <rvba> allenap: I guess you need to try a real upgrade to see what happens.
[12:28] <allenap> rvba: Okay.
[12:32] <rvba> allenap: if you try it on canonistack, do not forget to move /var/lib/maas/boot-resources to /mnt otherwise you won't be able to import the images (/ is too small for that).
[12:33] <allenap> rvba: Ta. I’m going to try it at home first.
[12:33] <rvba> (I usually use canonistack when testing things related to the images because the import is much faster there)
[12:34] <allenap> rvba: It always takes me about 5 hours to actually get a usable instance there :-.
[12:34] <allenap> :-/ even
[12:35] <rvba> I really need to polish and then publish the scripts I use for this.  All it takes is one command and 5 minutes of waiting.
[12:49]  * gmb -> afk for a bit
[14:29] <LiveOne> HI!
[15:23] <d4rkn3t> Hello everyone, please I need help on MaaS, and bind9. The problem is when I try to make the bootstrap of the node via Juju the command ssh has an error in the connection session, Bind not resolve the hostname. If I try to use ssh with the node's IP it works. Is there someone can help me, please?
[15:34] <rvba> d4rkn3t: Can you test if the MAAS DNS server can resolve your node's hostname by running this on the MAAS server:  `host <hostname>.<domain> localhost`
[15:36] <d4rkn3t> rvba:  I've not set a domain, I've set just the hostname on /etc/hosts file on Region Controller.
[15:36] <rvba> d4rkn3t: Do you mean that you're not using MAAS' DNS server?
[15:38] <d4rkn3t> I use it, I've set it on the cluster section the interface in "Manage DHCP and DNS"
[15:39] <d4rkn3t> rvba: and I see the zone in /etc/bind/maas/..... If I try to add the hostname with its IP on hosts file it works
[15:40] <rvba> d4rkn3t: the point of the DNS server is that you don't have to fiddle with /etc/hosts.
[15:41] <rvba> d4rkn3t: the domain by default is '.maas'.
[15:41] <d4rkn3t> it's right,
[15:42] <d4rkn3t> if I edit a zone I see this "@   IN    SOA maas. nobody.example.com. (
[15:42] <d4rkn3t><PHONE_NUMBER> ; serial
[15:42] <d4rkn3t>               600 ; Refresh
[15:42] <d4rkn3t>               1800 ; Retry
[15:42] <d4rkn3t>               604800 ; Expire
[15:42] <d4rkn3t>               300 ; TTL
[15:42] <d4rkn3t>               )
[15:42] <d4rkn3t> "
[15:42] <rvba> MAAS manages the zone file itself.  You shouldn't have to change it manually.
[15:44] <d4rkn3t> you right, but it not works I've also try to start the node without use Juju trying to connect via ssh used one time the IP, and it's works, then used hostname and it's not works
[15:46] <rvba> Back to my original suggestion, can you try running the command I pasted above?
[15:48] <d4rkn3t> rvba: ok, the command used in juju is this "ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i /home/richardsith/.juju/ssh/juju_id_rsa -i /home/richardsith/.ssh/id_rsa ubuntu@MaaSCCSvr1Node1 /bin/bash"
[15:49] <d4rkn3t> if I try to run it changing the hostname "@MaaSCCSvr1Node1" with its IP the ssh connection works
[15:49] <LiveOne> Hi.. u suggest using MAAS and JuJu to manage Openstack ?  good route for baremetal offsite dedicated severs
[15:49] <LiveOne> private/public
[15:50] <rvba> d4rkn3t: I understand; now we need to make sure MAAS' DNS server is working as expected; to do that I suggest running the command I pasted above.
[15:50] <d4rkn3t> rvba: ops without "@"
[15:52] <d4rkn3t> host MaaSCCSvr1Node1. localhost
[15:52] <d4rkn3t> Using domain server:
[15:52] <d4rkn3t> Name: localhost
[15:52] <d4rkn3t> Address: ::1#53
[15:52] <d4rkn3t> Aliases:
[15:52] <d4rkn3t> Host MaaSCCSvr1Node1. not found: 3(NXDOMAIN)
[15:53] <rvba> d4rkn3t: you need to use the default domain 'maas'.  host MaaSCCSvr1Node1.maas localhost
[15:53] <d4rkn3t> rvba: ops sorry the result is this "host MaaSCCSvr1Node1.maas localhost
[15:53] <d4rkn3t> Using domain server:
[15:53] <d4rkn3t> Name: localhost
[15:53] <d4rkn3t> Address: ::1#53
[15:53] <d4rkn3t> Aliases:
[15:53] <d4rkn3t> MaaSCCSvr1Node1.maas is an alias for 1-1-2-21.maas.
[15:53] <d4rkn3t> 1-1-2-21.maas has address <IP_ADDRESS>
[15:53] <d4rkn3t> "
[15:53] <rvba> Okay, so the DNS server works fine.
[15:54] <d4rkn3t> rvba: where is the problem????
[15:54] <rvba> Now, on the machine where you run Juju, you need to edit /etc/resolv.conf to add 'nameserver <IP of the MAAS server>'
[15:55] <rvba> This way, Juju will use MAAS' DNS server to resolve the node's IPs.
[15:56] <d4rkn3t> I've done it
[15:56] <d4rkn3t> but Juju and MaaS are installed on the same machine
[15:59] <rvba> d4rkn3t: it's not clear to me why Juju doesn't seem to be using the domain 'maas' but an easy workaround is to add 'search maas' at the top of your resolv.conf file.
[16:01] <rvba> d4rkn3t: if they are on the same machine then you need to put 'nameserver <IP_ADDRESS>' in resolv.conf
[16:04] <d4rkn3t> I'm trying to change the nameserver
[16:10] <d4rkn3t> wait, I want to explain which the virtual environment is: I've created a VM as Region Cluster and 2 VM as Cluster Controller then I've added 2 node to RC. After to changed their status in ready I've installed juju on RC and run the command to bootstrap the node
[16:30] <d4rkn3t> rvba: I've resolved that....I've added <IP_ADDRESS> on RC and then add .maas on FQDN....thanks a lot for your support
[16:40] <rvba> d4rkn3t: welcome


[17:46] <adom> love finding out that my system rebooted so I lost my screen session...did I miss anything important? ;)
[17:57] <adom> ...then you find out you have to fix something and need to reconnect...
[19:54] <swift110-phone_> Hey adom
[20:46] <swift110-phone_> Here is my latest audio.  http://hackerpublicradio.org/local/hpr2467.ogg


[15:01] <barry> #startmeeting
[15:01] <MootBot> Meeting started at 09:01. The chair is barry.
[15:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:01] <barry> hello everyone and welcome to this week's ameu reviewers meeting.  who's here today?
[15:01] <rockstar> me
[15:01] <allenap> me
[15:01] <gmb> me
[15:01] <intellectronica> moi
[15:01] <vednis> me
[15:01] <noodles775> here
[15:01] <vednis> argh
[15:02] <mars> me
[15:02] <gary_poster> me
[15:03] <flacoste> me
[15:03] <barry> adeuring: ping
[15:03] <barry> bac sends his apologies
[15:03] <adeuring> me, soory
[15:03] <salgado> me
[15:03] <barry> cprov, danilo_ EdwinGrubbs ping
[15:04] <barry> sinzui: ping
[15:04] <EdwinGrubbs> me
[15:04] <sinzui> me
[15:04] <barry> [TOPIC] agenda
[15:04] <MootBot> New Topic:  agenda
[15:04] <barry>  * Roll call
[15:04] <barry>  * Action items
[15:04] <barry>  * Mentoring update
[15:04] <barry>  * Peanut gallery (anything not on the agenda)
[15:04] <barry> meager agenda today
[15:04] <barry> [TOPIC]  * Action items
[15:04] <MootBot> New Topic:   * Action items
[15:04] <barry>  * mars to update JavaScriptReviewNotes with recent EIBTI decision
[15:05] <mars> no done
[15:05] <mars> give me five minutes :)
[15:06] <barry> :)
[15:06] <barry>  * gary_poster to take importfascist and rSP() discussion to ml
[15:06] <gary_poster> barry: no, I am an evil human being :-)
[15:06] <barry> gary_poster: maybe you are doing the world good by your delay :)
[15:06] <gary_poster> barry: maybe so
[15:07] <barry>  * allenap to look into storm/sqlobject result set compatibility
[15:07] <gary_poster> :-)
[15:07] <flacoste> i think this is done?
[15:07] <allenap> Yep, done :)
[15:07] <barry> yay, thanks!
[15:07] <barry>  * flacoste to work on API reviewer cheat sheet
[15:07] <cprov> me
[15:07]  * flacoste whistles
[15:07] <flacoste> innocently
[15:08] <barry> flacoste: i have a different "whistling" tune running through my head right now :)
[15:08] <rockstar> Andy Griffith?
[15:09] <barry> rockstar: i was thinking of snow white
[15:09] <barry> [TOPIC] mentoring update
[15:09] <MootBot> New Topic:  mentoring update
[15:09] <barry> any feedback from mentors or mentats?
[15:10] <adeuring> good work from Henning
[15:10]  * noodles775 has first day tomorrow, so no feedback yet :)
[15:10] <barry> adeuring: good to hear.  i think henninge is afk atm?
[15:11] <adeuring> yes, seems so.
[15:11] <barry> noodles775: you must be simply overwhelmed with anticipation and excitement :)
[15:11] <barry> cool
[15:11] <noodles775> barry: Indeed :)
[15:11] <barry> thanks, any other feedback?
[15:12] <barry> [TOPIC] peanut gallery (anything not on the agenda)
[15:12] <MootBot> New Topic:  peanut gallery (anything not on the agenda)
[15:12] <barry> does anybody have anything for today?
[15:13] <intellectronica> yes
[15:13] <intellectronica> a couple of notes about js. one specific one general
[15:13] <intellectronica> specific: don't forget that the minifier is stupid, and needs you to assign string literals to variables if you want them minified
[15:14] <intellectronica> general: pay attention to the cheat sheet, as it evolves. consider subscribing to it
[15:14] <intellectronica> that's it
[15:14] <barry> intellectronica: can you post the cheat sheet url here again?
[15:15] <intellectronica> https://dev.launchpad.net/JavaScriptReviewNotes
[15:15] <barry> intellectronica: thanks
[15:15] <barry> anything else?
[15:16] <barry> if not, then we can end the meeting in record time
[15:16] <barry> 5
[15:16] <barry> 4
[15:17] <barry> 3
[15:17] <barry> 2
[15:17] <barry> 1
[15:17] <gary_poster> wait...wait...wait!  no, just kidding :-D
[15:17] <barry> #endmeeting
[15:17] <MootBot> Meeting finished at 09:17.
[15:17]  * barry resolves that gary_poster has to run the next 5 meetings
[15:17] <gary_poster> lol
[15:18] <barry> :)
[15:18] <barry> bye bye
[15:18] <gary_poster> thanks barry


[07:12] <didrocks> good morning
[07:13] <duflu> Morning didrocks
[07:15] <lissyx> hello
[07:17] <didrocks> hey duflu, lissyx
[07:18] <lissyx> i'm experimentign a lot of crashes of rdd process on firefox nightly (non snap) on 22.04
[07:18] <duflu> Hi lissyx
[07:18] <lissyx> this is due to us enabling va-api recently by default
[07:18] <lissyx> cf https://bugzilla.mozilla.org/show_bug.cgi?id=1777200 and https://bugzilla.mozilla.org/show_bug.cgi?id=1752494
[07:18] <lissyx> now it looks like we expected AMD GPUs to behave well on Mesa 21.0+, and it seems not to be the case
[07:20] <lissyx> I'd like to confirm first it is a driver-side issue, would you know some context on that matter?
[07:28] <jibel> Good morning
[07:44] <duflu> Morning jibel
[08:06] <seb128> hey there, I think I went head down in resuming things I started yesterday and forgot the morning greeting today!
[08:13] <duflu> Hi seb128, you didn't really miss anything
[08:20] <seb128> hey duflu, great :)
[08:36] <lissyx> stransky told me it looks like an upstream issue, so https://gitlab.freedesktop.org/mesa/mesa/-/issues/6767
[08:38] <lissyx> seb128, ^ do you need me to also file an issue on launchpad?
[08:39] <seb128> lissyx, it wouldn't hurt, especially if upstream gets a fix and we want to cherry pick/SRU it for Ubuntu
[08:41] <lissyx> whaa...
[08:41] <lissyx> https://bugs.launchpad.net/ubuntu/+filebug redirects me to wiki instructions ?!
[08:43] <RikMills> lissyx: it should do that. you need to file the bug against the correct source package
[08:43] <lissyx> pretty sure in the past it used not to
[08:43] <lissyx> maybe long time ago
[08:43] <lissyx> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1980341
[08:44] <RikMills> it was changed so we do not get lots of bugs filed against just 'ubuntu' which is not very helpful
[08:44] <lissyx> (it's just links to upstream, I dont think it's useful I copy/paste all the same infos)
[10:09] <seb128> lissyx, the bugsquad members don't have the redirect, maybe you were member and expired?
[10:10] <lissyx> I dont think
[10:10] <lissyx> since I dont know what that is :)
[10:10] <seb128> k, maybe you remember from before the time they changed that, or you tried on a package name and not ubuntu/ before
[11:23] <seb128> lissyx, btw how do I tell if firefox is managing to use vaapi on my machine?
[11:59] <jbicha> good morning
[12:03] <KGB-0> gnome-shell ubuntu/master f9faf0d Nathan Pratta Teodosio debian/ (7 files in 2 dirs) * Drop support for the old gnome-control-center * https://deb.li/5Gm2
[12:06] <lissyx> seb128, I dont remember :)
[12:23] <seb128> jbicha, hey, I commented on gitlab but in case you don't regularly check email, the issue with gcc and RTL is that we are currently missing gtk4 translations and the direction is defined in the translation
[12:24] <jbicha> seb128: so it's a duplicate of bug 1947698 ?
[12:25] <seb128> jbicha, likely
[12:25] <seb128> how come we don't have translations for gtk4 and didn't notice? :-(
[12:26] <seb128> and why is gtk4 not using dh-sequence-gnome despite having a control.in? how is that even working?
[12:26] <Wimpy> Afternoon desktoppers o/
[12:26] <seb128> hey Wimpy, how are you?
[12:27] <Wimpy> Very well thanks seb128 :-)
[12:27] <Wimpy> Yourself?
[12:27] <jbicha> gtk uses an extra complicated debian/control.in structure. I don't think the complication is necessary but I didn't know if it was worth dismantling it
[12:28] <seb128> Wimpy, I'm alright thanks, buuuusy as usual!
[12:29] <seb128> jbicha, I assigned you a card, please try to work on it this week + SRU if possible, we need that fixes for .1
[12:29] <Wimpy> seb128: What is keeping you busy? Anything fun? :-)
[12:30] <jbicha> seb128: do you know when we can start getting kinetic langpacks built?
[12:31] <seb128> jbicha, we already have, see https://launchpad.net/ubuntu/+source/language-pack-gnome-fr for example from june 26th
[12:32] <jbicha> good
[12:32] <seb128> Wimpy, atm I'm mostly trying to stick on top of LTS issues like ^, .1 freeze is coming
[12:32] <Wimpy> seb128: wow .1 already? When is it due?
[12:33] <seb128> jbicha, you can probably copy my libnma debian/rules hack if we don't want to use dh-gnome
[12:33] <seb128> Wimpy, early august, which means freeze end of july, with review&validation delays for the SRUs it means we need to land things in the next weeks
[12:34] <Wimpy> Comes around fast doesn't it :-)
[12:34] <seb128> Wimpy, how are things for you? liking the work? still having time for ubuntu mate fun? ;)
[12:35] <Wimpy> WOrks is good. Conference season so been mega busy for weeks. Taking a few days off for my daughters birthday :-)
[12:35] <Wimpy> seb128: I've been working on a different hobby project recently. It uses gnome-flashback.
[12:36] <Wimpy> In fact, I have a question. What are the conditions for the Yaru theme variant chooser to be made visible in gnome-control-center?
[12:37] <Wimpy> seb128: I've put together a minimal desktop as an escape hatch for my project. g-c-c is working, but missing a couple of features.
[12:37] <Wimpy> Probably because gnome-shell is entirely absent.
[12:37] <Wimpy> Anyway, the project is a retro game emulation OS for Raspberry Pi built with Ubuntu 22.04 :-)
[12:39] <seb128> sounds like a fun one :)
[12:41] <lissyx> seb128, there's a VAAPI in about:support but it just shows if it's going to try it
[12:43] <jbicha> Wimpy: it only shows when "ubuntu" is present in XDG_CURRENT_DESKTOP (default session is ubuntu:GNOME) but you're going to get all the other Ubuntu customizations that way too
[12:44] <Wimpy> jbicha: Ah, thanks.
[12:44] <seb128> lissyx, so nothing telling you once you started playing if that's actually using the right backend? chromium has an about://media-internals giving you those details
[12:44] <Wimpy> jbicha: I'll test it and see what happens :-)
[12:44] <lissyx> seb128, I'm not really working on media, so I dont really know
[12:44] <lissyx> I can ask
[12:45] <jbicha> the goal is to get the color switcher into upstream GNOME, hopefully for GNOME 43
[12:45] <seb128> lissyx, don't bother, I was asking in case because I was curious whether my intel setup was using vaapi after seeing your morning report
[12:45] <lissyx> seb128, for sure you should see it on stdout/stderr when it tries to load vaapi
[12:45] <seb128> jbicha, is anyone working on that?
[12:46] <seb128> lissyx, I managed to get output from libva by setting MOZ_LOG="PlatformDecoderModule:1" but I'm unsure if that tells me the end result
[12:46] <seb128> anyway, not important
[12:46] <jbicha> seb128: I haven't seen any progress on it this cycle. From our side, I believe Trevinho wanted to work on it
[12:47] <lissyx> seb128, so, it looks like we have a new hire working on that and it's expected to land next week
[12:47] <lissyx> so next week, nightly should show actual status in about:support
[12:47] <seb128> jbicha, right, after tilling and libadwaita and $stack_of_things_we_need_magic_marco_for, not likely
[12:47] <seb128> lissyx, ah, great, thanks
[12:47] <jbicha> I meant this is the libadwaita thing basically
[12:48] <seb128> jbicha, well we first need to unblock the discussion and get an agreement of what would be acceptable
[12:48] <seb128> which seems stucked
[12:48] <seb128> then we need to work on the solution...
[12:49] <jbicha> yeah, it's a lot to do in a short time, so GNOME 44 is more likely
[12:56] <seb128> jbicha, I'm a bit confused at why xdg-desktop-portal-gnome fileselector are showing translations if gtk translations aren't there
[12:57] <seb128> hum, seems like it retranslate some of the existing strings from its own sources, that would explain
[12:58] <jbicha> it's a mix of translated & untranslated for me so maybe the fileselector reimplements the gtk fileselector
[12:59] <seb128> they use gtk_file_chooser_dialog_new , https://gnome.pages.gitlab.gnome.org/gtk/gtk4/class.FileChooserDialog.html
[12:59] <seb128> which let you specify the dialog actions and label
[13:00] <seb128> k, that explains
[13:00] <seb128> it also explain why some of the strings in the selector are untranslated which I was wondering about but didn't find time to investigate
[13:00] <jbicha> yeah, it's basically the header and footer bars which are translated
[13:00] <seb128> I didn't expect it would turn out being the gtk translation being missing :/
[13:01] <seb128> jbicha, and the favorite folder names
[13:01] <seb128> since that's coming from the xdg config
[13:01] <jbicha> right & I didn't accept the dialog to translate those :) :)
[13:42] <jbicha> seb128: the gtk debian/control.in magic is ancient, lol https://salsa.debian.org/gnome-team/gtk4/-/commit/041ded809
[13:43] <seb128> lol
[13:44] <jbicha> I'll go ahead and do a simple fix now, but I believe there won't be objections to just doing it like the rest of Debian GNOME later
[13:45] <seb128> 👍
[13:47] <jbicha> seb128: I guess it's because gtk4 uses meson that it was affected but not gtk3
[13:50] <KGB-0> gtk4 ubuntu/master 3fc54d9 Jeremy Bicha * pushed 44 commits (first 5 follow) * https://deb.li/Z6rG
[13:50] <KGB-0> gtk4 ubuntu/master 986fd99 Matthias Clasen gtk/gtktext.c * Merge branch 'blink-assertion-for-4-6' into 'gtk-4-6' * https://deb.li/vp3U
[13:50] <KGB-0> gtk4 ubuntu/master 91d2e1b Matthias Clasen gtk/a11y/gtkatspicontext.c * Merge branch 'stackpage-fix-for-4-6' into 'gtk-4-6' * https://deb.li/3sSJF
[13:50] <KGB-0> gtk4 ubuntu/master 15ea0c4 Laurent Bigonville debian/ control control.in * debian/control.in: Disable librsvg BD on architectures where it's not building * https://deb.li/arZU
[13:51] <KGB-0> gtk4 ubuntu/master 75821de Matthias Clasen gdk/wayland/cursor/wayland-cursor.c * wayland: scale cursors to the right size * https://deb.li/3drTM
[13:51] <KGB-0> gtk4 ubuntu/master 1523fec Matthias Clasen gdk/wayland/cursor/wayland-cursor.c * Merge branch 'wayland-cursor-scale2-for-4-6' into 'gtk-4-6' * https://deb.li/uQYy
[13:52] <seb128> jbicha, ?
[13:52] <seb128> jbicha, the reason is works for gtk3 is because we have that delta
[13:52] <seb128>     + debian/control.in: Build-Depend on dh-sequence-translations
[13:52] <seb128> why do you mean by because of meson?
[13:55] <jbicha> never mind, I was looking at the wrong branch
[14:00] <seb128> brb, changing location
[16:47] <Eickmeyer> Hey! Can somebody open a track for the gnome-3-28-1804 snap? I need a stable/ubuntu-##.## as I need it seeded in Ubuntu Studio.
[16:53] <diddledani> Eickmeyer: I'm not sure. The Ubuntu desktop-minimal seed for jammy shows `* snap:snap-store` as an item, but somehow that gets converted to installing a jammy-specific channel IIRC
[16:54] <Eickmeyer[m]> diddledani: Here's the issue I'm running into: https://launchpadlibrarian.net/610430884/buildlog_ubuntu_kinetic_amd64_ubuntustudio_BUILDING.txt.gz
[16:55] <Eickmeyer[m]> The snap "freeshow" (which is mine, btw) is an electron app which requires gnome-3-28-1804 (for some reason), which has no stable/ubuntu-##.## track for some reason.
[16:55] <diddledani> aah, you're missing a track in the gnome platform snap. I figured you were asking to override which track it was installed from (or maybe you're asking for either?)
[16:56] <Eickmeyer[m]> Yeah, that's the issue.
[16:56] <Eickmeyer[m]> And there's no way to specify a track in a seed that I'm aware of.
[16:57] <diddledani> odd. there's no tracks for the `gnome-3-38-2004` either and that's seeded in Jammy for Ubuntu desktop-minimal
[16:58] <Eickmeyer[m]> Yeah, which is funny because I have that seeded for Firefox no problem.
[17:01] <diddledani> there's no tracks for freeshow, either, and that got installed fine despite the commandline requesting `snap download --cohort= --channel=stable/ubuntu-22.10 freeshow`. This seems flakey - the command lines are arbitrarily flipflopping between requesting a stable/ubuntu-22.10 channel and not
[17:01] <Eickmeyer[m]> That's because, per the instructions (and mwhudson 's instructions) I made a track temporarily and closed it.
[17:02] <diddledani> aah
[17:02] <Eickmeyer[m]> So, that's really all that has to happen. A track needs to be opened and closed with that format.
[17:53] <jbicha> Eickmeyer[m]: could you update the snap to use gnome-3-38-2004 instead of the older version?
[17:53] <Eickmeyer[m]> jbicha: I wish. Unfortunately, electron-builder is stuck on the older 3-28-1804 and I've reseached ways to update it to no avail.
[17:56] <jbicha> Eickmeyer[m]: could you email Ken and Seb about needing the track opened and mention why you need the older gnome content snap?
[17:57] <Eickmeyer[m]> I'm going to throw a github issue up and explain that 1804 is hitting EOSS and that they should update it to the newer snap dep asap, but that doesn't fix the problem now.
[17:58] <Eickmeyer[m]> jbicha: I can do that. This is a problem for any electron app to be seeded at all, I just happen to be the guinea pig.
[18:04] <diddledani> Eickmeyer[m]: try setting the seed to `* snap:gnome-3-28-1804=latest/stable`
[18:04] <Eickmeyer[m]> I'll try that, thanks.
[18:04] <diddledani> (I've been going deep into google and launchpad-git repos to figure out how the live builder works
[18:04] <diddledani> ref https://git.launchpad.net/livecd-rootfs/tree/live-build/functions#n715
[18:05] <Eickmeyer[m]> diddledani: If this works, you'll be a life saver.
[18:06] <Eickmeyer[m]> The cron job hasn't started yet (should in the next few minutes), so we'll see soon.
[18:07] <diddledani> looks like it can be in the form of snap_name/classic=track/risk/branch (the /classic is optional and indicates to use --classic to install the snap, and =track/risk/branch is also optional to indicate the channel to install from)
[18:07] <diddledani> if the channel isn't specified and it's not core* then it will default to using `stable/ubuntu-$(release_ver)`
[18:13] <Eickmeyer[m]> I see. I hadn't investigated the code, tbh, nor did I know where to look.
[18:14] <seb128> diddledani, Eickmeyer[m], could you avoid such hacks please?
[18:14] <seb128> Eickmeyer[m], also do you have a report about the why electron-builder couldn't use new gnome versions?
[18:15] <Eickmeyer[m]> seb128: I would love to if I knew the proper way to do things.
[18:15] <Eickmeyer[m]> Or if it were properly documented.
[18:15] <diddledani> seb128: it's hardly a hack when it's intended as a feature of livecd-rootfs
[18:15] <seb128> diddledani, it's wrong though
[18:15] <Eickmeyer[m]> seb128: It's hard-coded and hasn't seen an update in over two years, prior to 20.04's release.
[18:15] <Eickmeyer[m]> The snap backend, that is.
[18:16] <diddledani> why is it wrong?
[18:16] <seb128> the reason we have a per-serie track and default to that is to have a safeguard in case of issue with that serie
[18:16] <seb128> we can reopen and publish to the serie and the installed system would default to it
[18:16] <seb128> you basically remove that safeguard by doing what you suggest
[18:24] <KGB-0> gtk4 signed tags 5d04f2b Jeremy Bicha ubuntu/4.6.5+ds-1ubuntu4 * gtk4 Debian release 4.6.5+ds-1ubuntu4 * https://deb.li/3ZpiE
[18:24] <KGB-0> gtk4 ubuntu/master c967583 Jeremy Bicha * pushed 6 commits (first 5 follow) * https://deb.li/BsAl
[18:24] <KGB-0> gtk4 ubuntu/master fb854b8 Jeremy Bicha debian/ control control.in * Build-Depend on dh-sequence-translations * https://deb.li/30thI
[18:24] <KGB-0> gtk4 ubuntu/master a4ebe87 Jeremy Bicha debian/changelog * releasing package gtk4 version 4.6.5+ds-1ubuntu2 * https://deb.li/dtej
[18:24] <KGB-0> gtk4 ubuntu/master 6916e68 Jeremy Bicha debian/rules * debian/rules: gtk4 builds 2 translation templates so handle them both * https://deb.li/31e2R
[18:24] <KGB-0> gtk4 ubuntu/master c2ca82d Jeremy Bicha debian/changelog * releasing package gtk4 version 4.6.5+ds-1ubuntu3 * https://deb.li/3pS0D
[18:24] <KGB-0> gtk4 ubuntu/master 04b5ecf Jeremy Bicha debian/rules * Fix the build directory for the previous upload * https://deb.li/iQsCz
[18:24] <KGB-0> gtk4 signed tags fe35d77 Jeremy Bicha ubuntu/4.6.5+ds-1ubuntu2 * gtk4 Debian release 4.6.5+ds-1ubuntu2 * https://deb.li/xt81
[18:30] <Eickmeyer[m]> seb128: I have an answer for you, and I can probably get a pull request going against this along with a github issue. Their default template is still referencing gnome-3-28-1804 for all electon apps. https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/templates/snap/snapcraft.yaml
[18:32] <Eickmeyer[m]> But, in the meantime, that still hinders Ubuntu Studio's iso images from building without the hack that diddledani showed me, so I'll go with that until a track can be opened, and until electron can fix the builder.
[18:47] <diddledani> seb128: oh I see, you mean specifically on the gnome platform snap, not on seeded snaps in general?
[18:48] <diddledani> I see no reason to avoid specifying a track for an app snap for example - ie one that isn’t part of the snap ecosystem, but maintained by a third party
[18:50] <diddledani> I get where you’re coming from for the gnome platform snap tho as there might be interactions with the desktop. However if there is a bad interaction then it should be fix for everyone now just the one Ubuntu release, so I still don’t understand the need for release specific tracks
[18:51] <diddledani> The gnome platform snaps aren’t specific to Ubuntu but are used wherever snaps run. Therefore a problem affecting an Ubuntu release will likely affect other distros too
[18:53] <diddledani> The whole point of snaps is that there shouldn’t be distro or release of distro changes for individual snaps including the platform snaps - if we’re doing a fix for one Ubuntu release then imo we’ve failed
[18:56] <seb128> diddledani, I think you didn't understand what I was saying
[18:58] <seb128> diddledani, the issue is that we ship Ubuntu, including for example $greatsoftware published by $new_nice_people as the default music player
[18:58] <seb128> diddledani, our user install Ubuntu and trust us for their working system
[18:59] <seb128> now in 3 years that publisher decide to do something to the software that screw our users
[19:00] <seb128> as Ubuntu we don't own the software nor it's published and can't fix it
[19:00] <seb128> but we can publish to that special channel and unscrew our users
[19:00] <diddledani> So you’re saying don’t seed a third party app at all?
[19:00] <seb128> we do, firefox for example
[19:01] <seb128> I'm just saying we need to be able to protect our OS and our users against anything wrong that could be done to the snap and would automatically reach every of our users
[19:01] <diddledani> so my suggestion of specifying the channel was specifically to unblock Eric because the gnome platform snap doesn’t have the track and the live build is failing because of that
[19:02] <seb128> right, it would have taken me less time to open that track than to have to argue that you shouldn't do that hack
[19:02] <seb128> which I'm doing now
[19:02] <diddledani> Ie specifying it on the first party snap of gnome-3-28-1804
[19:03] <Eickmeyer[m]> seb128: just let me know when you've got the track open so I can fix the ubuntustudio seed.
[19:03] <seb128> Eickmeyer[m], you need it for 22.10?
[19:03] <Eickmeyer[m]> BTW, fwiw, latest build succeeded.
[19:03] <Eickmeyer[m]> seb128: Yes.
[19:04] <Eickmeyer[m]> I'll be sending the electron-builder devs a PR.
[19:05] <diddledani> electron builder has often dragged behind the rest of the snap world so it’s not surprising they’re still using core18
[19:05] <ogra> Eickmeyer[m], note that you want to bump the `base:` along with the extension ... if you bump to the -2004 gnome extension the package build should use the core20 base
[19:06] <Eickmeyer> ogra: Yeah, figured.
[19:06] <ogra> k
[19:09] <seb128> Eickmeyer, diddledani, bah, unlucky it seems I'm not a collaborator on that specific snap and Ken just left for holidays and won't be back before a while, I guess you can keep the hack for now...
[19:10] <Eickmeyer[m]> seb128: ack
[19:10] <diddledani> Bah!
[19:11] <Eickmeyer[m]> I'll just email Ken so there's a paper trail since he's not likely to see this.
[19:11] <seb128> we should automate that for every seeded Canonical snap on new serie opening
[19:11] <seb128> Eickmeyer[m], +1
[19:11] <diddledani> Hopefully Ken sent my job application to Mark before leaving 😉
[19:11] <Eickmeyer[m]> seb128: That's a really good idea, would prevent situations like this from happening in the future.
[19:12] <diddledani> Agreed. I was gonna suggest that we get some automation on new series to open tracks on all the snaps that have series specifics
[19:15] <seb128> diddledani, he did
[19:16] <diddledani> yey
[19:16]  * diddledani twiddles her thumbs
[19:16] <seb128> diddledani, the issue with automation is that you need the automation to be owned by someone who is contributor to all the snaps
[19:16] <seb128> which I'm unsure we have
[19:16] <diddledani> aah. yeah.
[19:16] <diddledani> that's a sticky point
[19:17] <seb128> but we could at least automate the ones we one + emails to the publishers of the other ones with steps they need to do
[19:20] <KGB-0> libsoup3 ubuntu/jammy 4e74352 Jeremy Bicha debian/ control control.in gbp.conf * Update Vcs fields * https://deb.li/8rDn
[19:20] <KGB-0> libsoup3 ubuntu/jammy d67a2a2 Jeremy Bicha debian/changelog * releasing package libsoup3 version 3.0.7-0ubuntu1 * https://deb.li/3oBo7
[19:21] <KGB-2> libsoup3 signed tags 075f040 Jeremy Bicha ubuntu/3.0.7-0ubuntu1 * libsoup3 Debian release 3.0.7-0ubuntu1 * https://deb.li/SAj0
[19:37] <diddledani> is livecd-rootfs project used by anyone other than ubuntu projects via launchpad? if not then it might be worth disabling the ability to specify/override the series-specific track once we've got processes in place to ensure the snaps are all appropriately configured on new series start-of-development
[20:33] <lissyx> seb128, not sure how much important that is, but my 22.04 was an upgrade during beta cycle (early march) from 21.10
[20:33] <lissyx> seb128, we just found out vainfo was showing inconsistency, since jammy is supposed to be 22.0.1 mesa but vainfo was returning 21.0.1
[20:33] <lissyx> seb128, I found about the inconsistency another way and fixed the va-api issue by reinstalling mesa-va-drivers
[20:34] <lissyx> seb128, what I am unsure iswhether I messed up manually or if it could have been some upgrade that silently failed at some point and got un-noticed
[20:35] <lissyx> (on the tram, about to get back home first two days in the paris office since more than two years now)
[20:35] <lissyx> seb128, so maybe a blip in space, or something good to know in case you get other reports of weird crashes on va-api related