[04:56] -SwissBot:#ubuntu-news- ::Security:: Episode 130 @ https://ubuntusecuritypodcast.org/episode-130/


[16:44] <Eickmeyer> OvenWerks: Do we have anything to add to the release notes? https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes/UbuntuStudio
[17:16] <OvenWerks> Eickmeyer: I don't know if it is worth mentioning that -controls is now the prefered method of starting jack or not.
[17:16] <Eickmeyer> OvenWerks: That might be good, and I thought we did that for 18.10, but it's not bad to reiterate.
[17:16] <OvenWerks> Eickmeyer: people may question the line: "If you need Long Term Support, it is recommended you use Ubuntu Studio Bionic 18.04 instead."
[17:17] <OvenWerks> As 18.04 was not released as LTS
[17:17] <OvenWerks> I think it is right though
[17:17] <OvenWerks> because the repos are lts
[17:18] <Eickmeyer> OvenWerks: Maybe modify it to be "If you need Long Term Support, it is recommended you use Ubuntu Studio Bionic 18.04 with the Ubuntu Studio Backports PPA."
[17:19] <OvenWerks> Sure. Speaking of which, if jackd2.0 comes out any time soon, it should be there too
[17:19] <Eickmeyer> Agreed. I think if it gets synced for EE, then we can backport it, but I hope we don't end up in dependency hell for that.
[17:19] <OvenWerks> (I can't remember if Falktx has released it or not)
[17:20] <Eickmeyer> Something like jackd2.0 would end up in Debian first.
[17:20] <OvenWerks> Jackd 2.0 is supposed to add any bits jackd1 has to jackd 2
[17:20] <Eickmeyer> Interesting, so backwards compatibility (finally).
[17:21] <OvenWerks> meta data, zita-ajbridge internally, etc
[17:21] <Eickmeyer> That would be good to have that running under one process as opposed to a cluster of external bridges.
[17:21] <OvenWerks> I don't think the internal zita-ajbridge will really help us... maybe.
[17:22] <OvenWerks> A plugged in USB device would still need an external bridge I think
[17:22] <Eickmeyer> You mean if hotplugged?
[17:23] <OvenWerks> jackd1 needs the bridge to be a part of the command line. maybe jackd2 will allow loading it after startup
[17:24] <OvenWerks> yes if hotplugged... even if not hotplugged, we want jack to keep running if the USB mic is unplugged
[17:24] <OvenWerks> Internal devices that can't be hot (un)plugged are ok.
[17:33] <Eickmeyer> Ok
[17:34]  * Eickmeyer is keeping a close eye on #ubuntu-release for the RC.
[17:41]  * OvenWerks has had more trouble with USB unplugging than the plugin.
[17:42] <OvenWerks> it seems unplugging a USB device freezes/zommbifys/whatever jackd before I can change the master device.
[17:43] <OvenWerks> So I have to kill -9 jackd before changing devices in that case
[17:44] <OvenWerks> In fact changing master devices on the fly has become less stable in the last jackd release.
[17:45] <OvenWerks> Even with the devices plugged in and running, switching from one to the other only works one or two times and then mucks jack up.
[17:47] <Eickmeyer> Yikes. Should we put that in the release notes (which I just updated big-time, btw): https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes/UbuntuStudio
[17:47] <OvenWerks> Eickmeyer: I don't think so. SM is not something a lot of people use ;)
[17:49] <OvenWerks> https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes/UbuntuStudio seems to be confused as to what release 19.02 is C or D
[17:50] <OvenWerks> It says "Getting Ubuntu Studio Cosmic Cuttlefish (19.04)"
[17:51] <Eickmeyer> Thanks for that catch. Fixed.
[17:51] <OvenWerks> right after it says: "Release Notes for Ubuntu Studio 19.04 Disco Dingo"
[17:51] <OvenWerks> looks good.
[17:53] <Eickmeyer> Cool. I'll probably be able to put a strikethru on the part about Ubiquity real soon since Ross and I fixed that, with Carlos Lobrano and the upstream developer's help.
[17:54] <OvenWerks> for: "NOTE: Derivitives of Ubuntu (Linux Mint, Kali Linux, etc.) are not supported." does that mean they are known not to work? That they have not been tried? That they likely work but don't ask help? ;)
[17:55] <Eickmeyer> They haven't been tested, and don't ask for help.
[17:55] <Eickmeyer> Basically, you're welcome to try it, but you're on your own.
[17:56] <OvenWerks> About what I thought. I expect it would for the  most part work with vanilla debian too.
[18:00] <OvenWerks> derivitives should just work but are often one or more cycles behind, sometime based on the last LTS plus one cycle
[18:06] <Eickmeyer> I just don't think it's something we have the resources to handle.
[19:04] <OvenWerks> right. I am not saying we should support it at all... though if someone asked about one of the dirivitives simply says the backports are valid starting based on ubuntustudio lts life
[19:05] <OvenWerks> they can figure out what they are using and do as they wish.
[19:06] <OvenWerks> but the statement "Not supported" is correct.
[23:56] <OvenWerks> krytarik: FYI, "Boost" is not turned off by default, but can be turned off (for better low latency performance) with -controls.
[23:57] <OvenWerks> krytarik: however, the boost speed will generally not show up unless the cpu is pushed quite hard.
[23:59] <krytarik> So there is switch for it in Controls too but they've overlooked it?


[12:25] <Unhammer> Hi, https://help.ubuntu.com/community/GnuPrivacyGuardHowto#Getting_your_key_signed says to use only the last 8 chars of the fingerprints, but that's quite unsafe: https://evil32.com/ – I'm not able to log in to edit the page though, could anyone with access fix? (I've got an Ubuntu account, but it just hangs when I try to get back to the page)
[15:04] <pmatulis> Unhammer, what text do you have in mind?


[14:27] <Eickmeyer> Hey all! Edubuntu is nearly over the hurdle of having daily Raspberry Pi images being built. That said, I've volunteered with tsimonq2 to get working on Raspberry Pi images for Lubuntu.
[14:27] <Eickmeyer> One caveat though: for first user configuration, since these are preinstalled images, Ubuntu Desktop and Edubuntu are utilizing the oem-config functionality of Ubiquity. How do we proceed with that for Lubuntu?
[15:04] <arraybolt3> I think we will probably need to get OEM Lubuntu installation going for that.
[15:04] <arraybolt3> Which Calamares supports, we just need to figure out how to configure it for that use case.
[15:05] <arraybolt3> That was something I intended to look into after getting the updater polished.
[15:53] <tsimonq2> BRING OUT THE LIST!
[15:53] <tsimonq2> *thunder in the background*
[15:53] <Eickmeyer> *monty python holy grail intensifies*
[16:08] <arraybolt3> tsimonq2: bring our infra back up first *ducks
[16:08] <arraybolt3> *
[16:09] <arraybolt3> seriously though, I'm too uncomfortable with doing packaging until at least git.lubuntu.me is back operational, the risk of overwriting each other's changes and failing to push things is too great. So I'm going to stick to code development and research until then (depending on how much time I find).
[16:10] <arraybolt3> the updater is really good in its current state though (and once the apt-get update additional feature is pushed it will be even nicer). There be some good stuff in my local branch that I'm excited to get out there.
[18:13] <tsimonq2> arraybolt3: What I meant to say before is that we do have full mirrors on GitHub for a reason. :)
[18:13] <arraybolt3> ohhhh
[18:13] <tsimonq2> arraybolt3: Every important repository in Gitea has an exact copy on GitHub
[18:13] <arraybolt3> right but we can't push to those right?
[18:13] <arraybolt3> What if I change things one way and you change things another way on the same package?
[18:14] <tsimonq2> We can, they'll just be overwritten when Gitea comes back up. Which was my suggestion about just keeping the commits locally and pushing to Gitea when it's back :)
[18:14] <arraybolt3> hmm
[18:14] <arraybolt3> then I guess careful coordination it is
[18:14] <arraybolt3> have you touched htop or obconf-qt yet?
[18:15] <tsimonq2> IIRC we don't have a packaging copy for htop, and Backports is essentially an NCR of what's in Sid/Noble
[18:15] <tsimonq2> Haven't looked at obconf-qt or calamares yet
[18:15] <arraybolt3> packaging copy? As in, you have uploaded it to Noble (or someone has) and we don't have that on our machines/Git yet?
[18:16] <arraybolt3> (just trying to make sure I understand)
[18:16] <arraybolt3> I'm happy to tackle obconf-qt, and possibly try Cala if I get a chance
[18:19] <tsimonq2> Meaning, we don't track htop in Git on our end :) same with Vim
[18:19] <tsimonq2> arraybolt3: sounds good :) I have a bunch of writing to do today, let me know if I can help, otherwise tomorrow I'll circle back.
[18:20] <arraybolt3> kk :)
[18:20] <tsimonq2> That being said, the first thing on my list will be verifying the lubuntu-update-notifier SRU for Lunar.
[23:52] <arraybolt3> !ping


[16:38] <stgraber> highvoltage: got any edubuntu time this week for release?
[16:39] <stgraber> highvoltage: I've just tested the live session on amd64, translations are now fine, ltsp-live works as expected, the installer looks fine and I don't see any remote content in unity
[16:39] <stgraber> so all of our final beta bugs appear to have been solved
[16:40] <stgraber> now doing a standard install, then doing the same thing with Chinese on i386 and will try and run standard update tests too
[16:40] <stgraber> I'm doing all that today since it's a public holiday here, then will mostly do Ubuntu stuff the rest of the week
[16:48] <stgraber> highvoltage: btw, I really like the new Edubuntu wallpaper!
[16:50] <stgraber> and install works fine including LTSP
[16:50] <stgraber> we still have that problem where the system doesn't reboot properly post-install though but I think I've got an idea as to what's going on there, will see if I'm right and if I am, I'll update edubuntu-live to fix that one for good
[17:15] <highvoltage> stgraber: yep, will have some time. bandwidth is a greate issue since I moved and waiting for my dsl to come along. but I guess rsync on 3g won't be /too/ heavy
[17:16] <highvoltage> stgraber: and... nice :)
[17:48] <stgraber> highvoltage: oops, looks like we've got an issue with edubuntu_default (the wallpaper)
[17:48] <stgraber> we're currently shipping a 0 byte .png and a .jpg that's the symlink
[17:48] <stgraber> ubiquity loads the .png and so do some older installs
[17:49] <stgraber> so those result in either crash or black screen
[17:49] <stgraber> I'll see if just making the .jpg a symlink is enough
[17:54] <stgraber> fix uploaded


[03:40] <jjesse> to push changes to the branch, is that bzr push? or bzr commit?
[03:42] <kgoetz> push
[03:43] <jjesse> thanks kgoetz
[03:44] <jjesse> my first commit in a long time
[03:45] <jjesse> hrm won't let me commit the changes that i made
[03:46] <jjesse> bzr status still shows the file is modiefied
[03:46] <jjesse> but bzr push shows now newrevisions
[03:51] <jjesse> oh well heading to bed
[04:01] <kgoetz> jjesse: you need to commit the change into your branch, then push it
[04:01] <kgoetz> (soryr for lag)
[06:52] <achandrashekar> hello. I have some suggestions and issues with the edubuntu guides wiki for ltsp setup in infrastructure mode. Some of which caused a system hangup. Is someone around to listen to the core issue and perhaps make the according changes to the guides?
[06:56] <achandrashekar> the issue lies with the use of a recommended scripted setup for smb-ldap that no longer pertains to 7.10 installs
[07:03] <achandrashekar> anyone there to field my concern?
[07:24] <dencrypt> https://help.ubuntu.com/community/Firefox3#preview
[07:25] <dencrypt> If anyone wanna write the 32bit part your welcome. I don't have 32bit system.
[07:47] <mdke> jjesse: if you use "bzr bind" to bind your branch to the one on Launchpad, then all you will need to do is to use bzr commit and it will commit directly to Launchpad
[07:47] <mdke> dencrypt: looks like a helpful page, thanks. Feel free to post to the mailing list to encourage someone else to contribute the 32 bit section
[07:55] <dencrypt> Any specific rules regarding the mailinglist?
[08:08] <mdke> dencrypt: not really. Have a look at https://wiki.ubuntu.com/DocumentationTeam/Contact
[08:08] <dencrypt> hehe. Too late ;)
[08:08] <dencrypt> made a post.
[08:08] <dencrypt> :)
[08:08] <mdke> that's fine, there aren't any rules there anyway


[19:58] <joanie> TheMuso: yo back at ya. It's not a question as much as a statement.  I saw Jono's blog and the associated blueprint item re Qt frontend for Orca. I am doing some preliminary changes (moving the rest of Orca's gui away from GtkBuilder). Then I will tackle a Qt gui for Orca.
[21:33] <TheMuso> joanie: Sweet. IMO its not a priority, but it is certainly a nice to have.
[21:33] <TheMuso> As this cycle I was going to at least look at what was required, but since you seem to want to take a stab at it, thats great.


[06:02] <oSoMoN> good morning desktoppers
[06:09] <duflu> Morning oSoMoN
[06:12] <oSoMoN> hey duflu
[06:13] <duflu> oSoMoN, you might have noticed I added high resolution scrolling (Firefox) to the 20.04 ideas doc :)
[06:15] <oSoMoN> duflu, I hadn't, thanks for the notice
[06:16] <duflu> On that note, there's about 2 frames latency in mutter between the touch and the actual scroll being displayed. I have fixes for both but only one has landed in time for 3.34 so far
[06:17] <duflu> That only matters though, if the app does high resolution scrolling
[06:47] <jibel> hi everyone
[06:50] <duflu> Hi jibel
[06:51] <oSoMoN> salut jibel
[07:24] <duflu> Morning seb128
[07:24] <seb128> hey duflu, good morning desktopers
[07:26] <seb128> duflu, how are you?
[07:27] <duflu> seb128, making progress on multiple fronts. How are you?
[07:27] <seb128> duflu, I'm good!
[07:28] <seb128> duflu, what are you digging into atm?
[07:28] <duflu> seb128, just got around to re-fixing an old bug; https://gitlab.gnome.org/GNOME/mutter/merge_requests/724
[07:28] <oSoMoN> salut seb128
[07:28] <seb128> lut oSoMoN, en forme ?
[07:29] <oSoMoN> ça va bien, et toi?
[07:30] <duflu> seb128, also the last(?) of the desktop-icons leak fixes landed upstream
[07:31] <seb128> duflu, ah nice
[07:31] <seb128> oSoMoN, ça va bien :)
[07:51] <marcustomlinson> morning oSoMoN duflu and seb128
[07:51] <seb128> hey marcustomlinson, how are you?
[07:51] <duflu> Morning marcustomlinson
[07:51] <seb128> marcustomlinson, good news, libreoffice builds fine with the new poppler, no need of code changes :)
[07:52] <marcustomlinson> seb128: \o/ \o/ \o/
[07:52] <marcustomlinson> seb128: was a pretty major update so that's amazing news
[07:52] <marcustomlinson> seb128: so to answer your earlier question, I was good, now I'm better :) How are you?
[07:55] <seb128> marcustomlinson, I'm good :)
[07:55] <marcustomlinson> seb128: shall I prep a new upload with that Replaces fix then?
[07:56] <seb128> marcustomlinson, while speaking of new versions, I'm trying to get us uptodate where it makes sense before ff, do you know what's the deal with liborcus 0.15? it was uploaded to experimental in Debian, unsure if we should get it or not?
[07:57] <seb128> marcustomlinson, @new upload, yes, though I might wait a couple of days to upload that transition
[07:57] <seb128> I don't want to stack it over the e-d-s one so might want to wait for that one to be uploaded, I needed to check with Laney
[07:59] <marcustomlinson> seb128: hmm, well we don't need liborcus 0.15 at this very stage. We could SRU it later if necessary perhaps
[08:00] <seb128> marcustomlinson, is it an unstable/risky version?
[08:00] <seb128> or do you default to "if it's not needed let's not take it"?
[08:00] <marcustomlinson> seb128: yeah I'd rather not risk breaking stuff that works last minute
[08:01] <marcustomlinson> seb128: it was tagged 5 days ago
[08:01] <seb128> k
[08:01] <seb128> my approach to the version tracking is "it's usually good to stay close from upstream"
[08:01] <seb128> especially in LTS-1, you want to get change in that cycle rather than in the LTS cycle if possible
[08:01] <seb128> give more testing room
[08:01] <Laney> yo
[08:02] <seb128> anyway, I'm not pushing for us to update it, I just want to record things so we know if we don't update by choice/decision or if we jsut didn't keep up and we should
[08:02] <seb128> hey Laney! how are you?
[08:02] <marcustomlinson> seb128: you're more experienced in this than me
[08:03] <oSoMoN> hey marcustomlinson
[08:03] <seb128> marcustomlinson, there is no right/wrong, it's a balance :)
[08:03] <seb128> if the Debian maintainer put it in experimental that's probably a clue we should be careful about it
[08:03] <seb128> I will put a note that we wait to see for that one
[08:03] <seb128> thx marcustomlinson
[08:03] <marcustomlinson> yes this ^
[08:04] <oSoMoN> hey Laney
[08:06] <RAOF> seb128: Once I've checked that the new autopkgtest for `installed-tests` works I'll push colord up to salsa (this may be tomorrow, now). Feel like sponsoring this time tomorrow? :)
[08:07] <Laney> hey seb128 oSoMoN marcustomlinson & RAOF
[08:07] <Laney> seb128: I'm good!
[08:07] <Laney> how's everyone else?
[08:08] <oSoMoN> I'm good
[08:08] <RAOF> Hey Laney !
[08:08] <seb128> RAOF, hey, sure
[08:08] <seb128> Laney, I'm good!
[08:10] <marcustomlinson> Laney: ja goed
[08:11] <Laney> :>
[08:11] <seb128> Laney, any eta on the e-d-s transition upload? does that need to go with the shell stack or not required? I'm asking in context of starting the poppler transition, I would prefer having stacking them together
[08:12] <Laney> yes it is required
[08:12] <Laney> gnome-shell depends on ecal
[08:12] <seb128> k
[08:12] <GunnarHj> Good morning all!
[08:12] <GunnarHj> Laney: I'm back about bug #1839605.
[08:12] <GunnarHj> As you may have seen on #ubuntu-release it's now in the xenial/bionic/disco new queues, waiting for your blessing.
[08:12] <seb128> do you think we might upload this week at this point or rather next?
[08:12] <Laney> don't know
[08:13] <Laney> need to upload the extensions
[08:13] <seb128> k
[08:13] <Laney> Marco needs to give us a fix for the flaky tests
[08:13] <Laney> could be
[08:13] <seb128> Trevinho, ^ what's the status of that?
[08:13] <Laney> but I also need to write some talk slides for guadec, so
[08:13] <Laney> he doesn't need hassling, it's fine
[08:13] <seb128> k
[08:13] <seb128> I might go ahead with poppler then
[08:14] <seb128> it feels like I've room to get that done before we are reading with GNOME
[08:14] <seb128> thx Laney
[08:14] <Laney> check the state of proposed first
[08:14] <Laney> if that ends up backing up for two weeks we'll have a problem
[08:14] <Laney> last I looked there were some transitions in progress there
[08:15] <seb128> there is a libvpx transition that would good to clear off first
[08:15] <seb128> right
[08:15] <seb128> I will start by trying to help clearing those then
[08:15] <seb128> thx Laney, useful hints ;-)
[08:15] <Laney> and you'll probably get some enemies if you make it harder:p
[08:15] <Laney> np!
[08:16] <seb128> Laney, jibel, I was busy with other things so didn't pay full attention yesterday after the meeting, but the ISO test issue is down to "need kernel team input"?
[08:16] <Laney> yes, and jibe_l said he'd file a bug and talk tot hem
[08:17] <seb128> great
[08:17] <seb128> thx :)
[08:18] <seb128> bah, stupid laptop, battery is flat again, co I'm relocating back from coffee place, brb
[08:21] <duflu> Morning Laney and GunnarHj
[08:23] <Laney> GunnarHj: Will look later
[08:23] <Laney> hey duflu
[08:25] <GunnarHj> Laney: Ok.
[08:45] <jibel> Laney, hi, I filed bug 1840122
[08:45] <Laney> woot
[08:56] <seb128> k, back now!
[08:57] <Laney> jibel: will you follow up with the kernel team or are you expecting foundations to look first since you filed on casper?
[08:57] <Laney> wb
[08:58] <seb128> thx :)
[08:58] <jibel> Laney, I'd start with Foundations
[08:58] <jibel> Laney, what do you think of this change https://launchpadlibrarian.net/434753737/casper_1.413_1.414.diff.gz ?
[08:59] <jibel> it changes the way / is mounted and could lead to the umount failure
[08:59] <Laney> didn't it start before then?
[08:59] <Laney> does sound interesting though
[08:59] <Laney> should be possible to try reverting that
[09:00] <jibel> or 1.412
[09:00] <jibel> it's the first attempt at fixing the same bug
[09:01] <jibel> we could try to revert at 1.411
[09:01] <Laney> sounds like a good idea to try
[09:01] <seb128> the issues started on jul 16th
[09:01] <seb128> which is the day casper 1.412/413 was uploaded
[09:01] <jibel> yeah and it matches 1.412
[09:01] <seb128> so it would match
[09:02] <Laney> please do give it a go
[09:02] <Laney> good finds
[09:02] <jibel> what's the easiest way to revert casper? extract the initrd, unpack it, downgrade casper, repack everything and boot from it?
[09:03] <Laney> probably "direct kernel boot" would avoid you having to repack the whole iso
[09:03] <jibel> yes that's what I meant
[09:04] <Laney> nod
[09:04] <jibel> i'll give it a go
[09:04] <Laney> that's the best way I know of
[09:05] <Laney> in this case we should have believed the testing :(
[09:05] <seb128> yeah...
[09:05] <seb128> how does that repack/direct kernel boot work?
[09:06] <seb128> I'm curious in case I need to try that one day
[09:07] <seb128> Laney, did you want to handle the new gtk merge/upload to eoan? if not I might have a go to it now
[09:07] <Laney> you do it please
[09:07] <seb128> k, thx
[09:07] <Laney> so you can get the initramfs and kernel out of an iso
[09:07] <jibel> seb128, you extract the kernel and the initrd from the iso and tells kvm to use these files instead of the ones in the iso
[09:07] <Laney> and virt-manager has options to use those
[09:07] <seb128> ah ok, cool
[09:07] <seb128> thx jibel Laney
[09:07] <seb128> I didn't know that was an option
[09:08] <jibel> seb128, qemu has  -kernel= and -initrd= arguments
[09:12] <seb128> I see, useful to know, thx!
[09:17] <seb128> Laney, do you remember why we stayed away from the newer tracker previous cycle? iirc there was some technical reason, like transition or some work to do but I don't remember the specifics...
[09:17] <seb128> jbicha, ^ or if you are around, I think you are the one who handled that back then
[09:18] <Laney> tracker 2.2?
[09:18] <seb128> GunnarHj, do you want to maybe handle the gnome-getting-started-docs and gnome-user-docs updates to the new serie? (bonus point if you do it in Debian first/as well, I can do sponsoring ;-)
[09:18] <Laney> not specifically no
[09:18] <seb128> Laney, yes
[09:18] <seb128> k
[09:18] <Laney> not just due to feature freeze?
[09:19] <seb128> I don't remember know, I think there was something
[09:19] <seb128> like work that would need to happen but no-one had time for
[09:19] <seb128> maybe a MIR, or a split/transition
[09:19] <Laney> hmm ok, I don't remember, sorry
[09:19] <seb128> no worry
[09:19] <seb128> maybe i'm just dreaming
[09:19] <seb128> let's see if Jeremy walk by at some point and remembers
[09:28] <oSoMoN> marcustomlinson, https://discourse.ubuntu.com/t/libreoffice-certain-bundled-fonts-are-missing-in-ubuntu/12212
[09:32] <marcustomlinson> oSoMoN: cool I'll todo it
[10:37] <GunnarHj> seb128: Yes, I plan to handle those for Ubuntu. Since there are some significant deltas, we usually bypass Debian, but sure, I can look at Debian too. Where should I put proposed uploads? Mentors?
[10:38] <seb128> GunnarHj, salsa, e.g https://salsa.debian.org/gnome-team/gnome-getting-started-docs
[10:38] <seb128> GunnarHj, thx
[10:38] <GunnarHj> seb128: Right, I forgot the repo. ;)
[10:38] <seb128> :-)
[10:48] <seb128> Trevinho, https://gitlab.gnome.org/GNOME/libnotify/merge_requests/5 has a trivial change requested (mentioning it in case you ddin't see it)
[10:48] <Trevinho> seb128: ah thanks for the ping
[10:48] <seb128> np!
[10:49] <Trevinho> Laney: are you happy with merging that upstream then=?
[10:52] <Laney> Trevinho: with what?
[10:52] <Laney> oh that
[10:52] <Laney> sry didn't read up
[10:54] <Laney> yeah, did you think about the ordering thing?
[11:23] <Laney>  folks | 0.11.4-1ubuntv3 | eoan/universe   | source
[11:23] <Laney> interesting
[11:27] <Trevinho> Laney: yeah, you mean weather what to pick first...
[11:27] <Trevinho> but I think this should go properly
[11:27] <Laney> yep
[11:27] <Laney> happy if you are
[11:30] <Trevinho> Laney: you saw the small diffs I applied to yours, right?
[11:32] <Laney> nope
[11:32] <Laney> I'm sure they are great though
[11:32] <Laney> got a link?
[11:33] <Trevinho> Laney: https://gitlab.gnome.org/GNOME/libnotify/merge_requests/5/diffs?diff_id=52149&start_sha=7f9dc9dd4c45870ae9d47bd2bcef99550757464e
[11:33] <Trevinho> Laney: the only thing I'm considering is that... if we're running from a snap probably is better to always priotize things inside the snap
[11:34] <Laney> yes that's what I meant with ordering
[11:34] <Laney> diff looks good except for the review comment seb128  pointed out
[11:36] <Trevinho> Laney: yeah, I already addressed that
[11:38] <Trevinho> Laney: so https://gitlab.gnome.org/GNOME/libnotify/merge_requests/5#note_580352
[11:39] <Laney> I said that in a comment somewhere :p
[11:39] <Laney> feel free to change it, it's a choice and wasn't sure what the right way was
[11:39] <Laney> probably snap first indeed
[11:42] <Trevinho> ok, let me move it down then
[11:43] <Laney> do test that in case it breaks in some weird way
[12:16] <jibel> Laney, so with 1.411 I don't get the umount error messages but it still doesn't reboot.
[12:43] <Trevinho> Laney: looking even more at libnotify still we've some issues around...
[13:01] <Trevinho> Laney: one reason why I added some reports in my libnotify change was to allow snap writers to figure out what's going on by just seeing the output, but maybe we can ignore this
[13:18] <Trevinho> Laney: I've pushed another version for libnotify, includes https://gitlab.gnome.org/GNOME/libnotify/merge_requests/5/diffs?diff_id=52719&start_sha=1f6135c96e8221215151ae21282f86766ec1c63f
[13:19] <Trevinho> so that now desktop files are properly parsed when the case is to just use SNAP_NAME (otherwise it would have happended a /
[13:19] <Trevinho> and also is fixed the case where an uri is passed
[13:21] <Laney> that's complicated enough that I have to review it properly, sorry, can't nod this through any more
[13:22] <Laney> and I'm busy writing slides for guadec now
[13:22] <Laney> did you remove all the times that function is called with multiple arguments? if so, drop the varargs stuff
[13:25] <Laney> would prefer it if we were to stick on the gnome 3.33 topic though
[13:28] <Laney> jibel: nothing to indicate a problem?
[13:30] <jibel> Laney, no, the other suspect would be your initial guess: kernel 5.0 -> 5.2
[13:31] <jibel> but I dont see how to revert it in a live session
[13:31] <jibel> without rebuilding the entire image
[13:32] <Laney> I dunno either
[13:34] <Trevinho> Laney: yeah, I was thinking to remove the va-args thing in fact
[13:37] <Laney> if it's unused
[13:37] <Laney> still do have to review it though, not quite clear to me what you've changed, why, what problem it fixes, and why it's better
[13:38] <seb128> Trevinho, I would suggest not spent more time on that today, I pointed out the trivial code fix this morning it was not to sidetrack you from other things for half the day...
[13:38] <seb128> other iteration on that can wait next week post ff
[13:38] <seb128> imho
[13:39] <Trevinho> yeah, I left that already alone
[13:39] <seb128> thx
[13:39] <Trevinho> I looked a bit on it just because it have been material for this, but looks not
[13:44] <seb128> Laney, did you hold on syncing the glib update from Debian? or just didn't look at it?
[13:46] <Laney> second one, that was only like 2 days ago
[13:46] <seb128> k, sorry, I'm looking for version that doesn't include the age (maybe would be an useful hint to have in a popover or such)
[13:47] <seb128> thx :)
[13:47] <Laney> it's good to test/sync if you want to
[13:47] <seb128> I'll install it and see how it goes
[13:47] <seb128> then sync later if it looks ok
[16:45] <ricotz> seb128, hi :), could you sync vala from debian/exp as well?
[18:02] <seb128> ricotz, hey, done
[18:14] <ricotz> seb128, thx
[18:17] <seb128> ricotz, thank you for handling the update :) shouldn't we move experimental/eoan to 0.45 btw? (and how much does that impact builds/requiring porting work)?
[18:18] <ricotz> seb128, absolutely, 0.45.90+ would be a recommended version for the upcoming release
[18:21] <ricotz> I don't know which 3rd-party projects would require patching, everything covered by GNOME builds
[18:23] <seb128> ricotz, do you plan to update in experimental?
[18:27] <ricotz> seb128, sure, I can do update salsa repo to 0.46
[18:27] <seb128> thx