[07:08] <lordievader> Good morning
[08:47] <victorh> hi guys. is anyone experienced with running ubuntu server on a pci-express solid state drive?
[09:56] <oskie> is it safe to install a new Ubuntu server (bionic) on a public IP, unfirewalled?
[10:02] <TJ-> oskie: lotuspsychje just copied your question to me since I only just arrived. Generally the answer is 'yes' but it can depend on what packages were selected at install time.
[10:07] <TJ-> oskie: E.g. there is usually a package delta between the ISO and the archive now (as bug-fixes, etc. are published) which /theoretically/ may fix vulnerabilities that could be publicly exploitable, but if you follow the usual sys-admin procedure which would be to apply default firewall rules on first boot the time-window for such an attempt would be only a minute or so /and/ an attacker would have to
[10:07] <TJ-> know in advance of the IP address, the exact version being installed, its vulnerability, and be able to launch the attack in a very narrow time window measured in seconds
[10:14] <ahasenack> good morning
[10:25] <victorh> morning
[10:29] <victorh> oskie: the default settings for the iptables is that none of the ports are open except for standard services as ssh. but for that matter the root account is also disabled.
[10:29] <victorh> so you should be fine, but it is not recommended
[10:29] <victorh> of course it is best so set up everything exactly how you'd like it before hooking it up to the bad and evil interwebs
[10:30] <victorh> for the newcomers: is anyone experienced with running ubuntu server on a pci-express solid state drive?
[10:37] <lotuspsychje> victorh: do you have one, or think to buy one
[10:44] <vlt> victorh: There are default iptables settings on Ubuntu server?
[10:46] <blackflow> there aren't
[10:46] <blackflow> there's uwf present iirc, but the iptables chains are of default policy ACCEPT with no rules
[10:46] <blackflow> *ufw
[10:56] <victorh> lotus: i have one. somehow its not working well with the pci-express active state power management
[10:57] <lotuspsychje> victorh: can you provide us a link of your ssd, volunteers might have ideas
[11:00] <oskie> TJ-, victorh thanks
[11:01] <TJ-> victorh: there are quite a few bugs arouund ASPM, there is an option to disable it in-kernel
[11:01] <oskie> I'm installing bionic from the live server ISO. Does it require an internet connection
[11:02] <oskie> ? I can't seem to continue from network config because it times out.
[11:10] <victorh> tj-: how you can check if it's disabled. I also tried to set it to performance, but in /sys/module/pcie_aspm/parameters/policy it still says default
[11:12] <TJ-> there's a boot-time kernel command-line option "pcie_aspm=off"
[11:12] <TJ-> victorh: you could use that as a diagnostic aid to prove if ASPM is definitely the cause
[11:12] <victorh> TJ-: yes, and it's set in the grub right?
[11:13] <TJ-> victorh: yes, you can set it manually at boot-time by tapping Esc key to get to GRUB boot menu and editing the boot entry's command-line, or set it permanently via /etc/default/grub GRUB_CMDLINE_LINUX=
[11:14] <victorh> TJ-: i've set it in the cmdline_linux_default
[11:14] <TJ-> victorh: and do "sudo update-grub" of course!
[11:14] <victorh> now it's "pcie_aspm=performance"
[11:15] <victorh> haha yes of course. easy to forget though
[11:15] <TJ-> I don't see "performance" as an option, only "off" or "force"
[11:15] <victorh> $ cat /sys/module/pcie_aspm/parameters/policy => [default] performance powersave
[11:15] <TJ-> victorh: see https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
[11:16] <victorh> TJ-: Thanks
[11:16] <victorh> i'll hook up again when I have more info
[11:16] <victorh> *afk going for lunch
[12:29] <tobias-urdin> coreycb: are canonical publishing stein packages? it's hard working with centos packages based on master and ubuntu rocky packages
[12:29] <tobias-urdin> also do you know if there is any effort on debian based packaging for moving out placement?
[13:15] <victorh> tobias: no idea, sorry
[13:32] <coreycb> tobias-urdin: yes but i don't think it's been tested much. you'll have to do this to enable for now: https://paste.ubuntu.com/p/ZnGZq2HVBt/
[13:32] <coreycb> tobias-urdin: note that we've dropped py2 packages for stein
[13:32] <coreycb> tobias-urdin: and yes, we're aware of placement but haven't created the package yet. hopefully will get that done soon.
[13:41] <tobias-urdin> coreycb: ok thanks, we are working on py3 for the puppet projects where RDO is also working on porting the packages to py3
[13:42] <tobias-urdin> there is effort to move placement out of nova as well, that why i asked, since it's hard to perform unless both has moved out to separate packages
[13:42] <coreycb> tobias-urdin: ok yes. i'll make placement a priority for this week.
[13:43] <coreycb> tobias-urdin: yay py3 :)
[13:43] <tobias-urdin> thank you coreycb!
[15:03] <faekjarz> Hi! Is there any boot option, or installer option, command line switch, that causes the alternate server installer (18.04.1 / LTS) to not setup any SWAP?
[15:04] <Slashman> hello, where can I ask about the ubuntu certification for Dell servers?
[15:05] <Slashman> previously I saw that the Dell R6415 was certified with ubuntu and now it seems it's not anymore
[15:05] <sdeziel> faekjarz: there should be a swap *file* in the root, no?
[15:06] <Slashman> in fact this server is completely gone from the ubuntu website https://certification.ubuntu.com/server/models/?query=R6415
[15:06] <sdeziel> faekjarz: what do you get from "swapon -s"?
[15:10] <faekjarz> sdeziel: in this case it's not relevant whether it's a file or a partition. The installer sets up swap, and i want to tell it not to do it. (i know, i can disable it later, but that's not the problem i intend to solve right now.)
[15:11] <sdeziel> faekjarz: oh OK, that's not what I understood, sorry
[15:12] <faekjarz> no worries
[15:55] <faekjarz> i could use btrfs; afaik, there's no swap allowed on btrfs …and the installer would comply
[16:00] <faekjarz> i stand corrected, just tested it and the alternate server installer creates a swap file on a btrfs m)
[16:45] <lordcirth> Can someone familiar with netplan tell me why this seemingly simple config doesn't work?  It works without the bridge, but the moment I add the bridge, it stops working.  Regardless of whether I put the address on the vlan or bridge.  Thanks!
[16:45] <lordcirth> http://paste.ubuntu.com/p/hT3f7BGpCs/
[16:46] <compdoc> are the bridges used for kvm?
[16:46] <compdoc> oh, vlans
[16:48] <lordcirth> For lxc, similar
[16:49] <lordcirth> We have 16.04 IaaS systems that have a 10Gb/s link with various dotted interfaces, each with a matching bridge, which lxc containers get attached to.  Works great. Trying to move to 18.04/netplan and it all breaks
[16:49] <lordcirth> Also we don't normally need an address on the lxc interface, but this machine does.
[16:50] <compdoc> I had problems too, but found that everything worked if I used netplan for the interfaces, then added the bridges in /etc/network/interfaces
[16:50] <compdoc> in 18.04
[16:52] <lordcirth> Well that's a bit odd
[16:54] <cyphermox> lordcirth: try something like this: https://paste.ubuntu.com/p/4WJZQ8DTCp/
[16:54] <cyphermox> if you define the physical interface by mac address it helps networkd do the right thing
[16:55] <lordcirth> cyphermox, ah, ok, I was about to ask what the key difference was.  I will try, thanks
[16:55] <cyphermox> the key diff is really the fact that there's a "match: macaddress: " for the physical device
[16:57] <lordcirth> cyphermox, should I use a custom name instead of enp0s8?
[16:57] <lordcirth> Does it matter?
[16:58] <cyphermox> nope
[16:58] <cyphermox> use whatever you want
[16:58] <cyphermox> in there I was testing more things
[16:58] <cyphermox> this is a config I have in production, but I do use that server to test some of the hairier configs
[16:59] <lordcirth> does rebooting without running 'netplan apply' apply things, or do you have to run it first?
[17:03] <cyphermox> rebooting always applies whatever is in the file
[17:03] <cyphermox> 'netplan apply' is just for if you want the changes to take effect immediately
[17:46] <xnox> jamespage, openstack-dashboard & ceph => are they switching to python3 by default and/or what is that blocked on?
[17:46] <xnox> i've tried looking into it, but failed to establish the missing parts.
[17:50] <lordcirth> cyphermox, so, I switched to matching on mac, and now it gets stuck on boot trying to bring the network up for ages, then it boots and works.  I'm confused
[17:55] <cyphermox> lordcirth: maybe run 'systemd-analyze blame' to see what is taking up time
[17:56] <lordcirth> cyphermox, 2min 66ms systemd-networkd-wait-online.service
[17:58] <lordcirth> syslog: systemd-networkd[465]: enp0s8: Link is not managed by us
[17:58] <lordcirth> That's odd
[17:58] <lordcirth> Does netplan rendering to networkd not count as managed by networkd?
[18:04] <cyphermox> probably a red herring unless you do DHCPv6
[18:08] <lordcirth> Ok.  Not sure how to track down the error
[18:18] <lordcirth> cyphermox, hmm, networkctl status -a shows br10 as "nocarrier: configuring" and the vlan tagged iface doesn't exist
[18:22] <lordcirth> enp0s8 is 'off'
[18:23] <cyphermox> that certainly won't help
[18:24] <cyphermox> you'll want to check your config, but also if the device is correctly connected, etc.
[18:24] <cyphermox> not much else I can help with; this depends a lot on your hardware and networkd
[18:24] <cyphermox> *network
[18:25] <lordcirth> It's in virtualbox, actually.  The virtual network is quite standard and functional
[18:34] <teward> does anyone know what the default I/O scheduler settings are for Ubuntu?
[18:34] <teward> Ubuntu Server*?
[18:34] <teward> I accidentally posted this in the wrong channel sorry for the crosspost
[18:36] <sdeziel> teward: grep CONFIG_DEFAULT_IOSCHED /boot/config-$(uname -r), says cfq here
[18:38] <sdeziel> teward: you might want to check /sys/block/$DEV/queue/scheduler as some dev type use a different scheduler (virtio == none)
[18:45] <teward> sdeziel: ack, #ubuntu-devel gave me some of the info too heh
[18:45] <teward> thanks
[18:45] <sdeziel> np
[18:52] <jamespage> xnox: tbh I think I'm just going to drop the py2 support from ceph and switch over to py3 wholesale
[18:52] <jamespage> xnox: coreycb is workingon the dashboard + plugins but it needs a new package to complete
[18:54] <coreycb> yep working on that right now (django-debreach for horizon)
[19:06] <xnox> jamespage, what about cloud-archive? are backports into that going to use py2 or py3?
[19:07] <xnox> coreycb, ooooh, nice.
[19:07] <jamespage> xnox: py3
[19:07] <xnox> ok
[19:45] <lordcirth> cyphermox, I'm trying netplan 0.40 from ubuntu-proposed, in case it's related to the bug...
[19:49] <lordcirth> Doesn't seem to have helped
[20:07] <lordcirth> cyphermox, so brctl show says the bridge has no interface.  adding 'vlan10' works perfectly and ping starts working.  Any idea why netplan refuses to connect br10 to vlan10?
[20:18] <cyphermox> lordcirth: not without looking at the full config
[20:18] <lordcirth> cyphermox, what files do you need?
[20:19] <cyphermox> anything in /etc/netplan
[20:20] <lordcirth> cyphermox, 10-tagged.yaml: http://paste.ubuntu.com/p/XZyrc4cPdf/
[20:21] <lordcirth> 01-netcfg.yaml: http://paste.ubuntu.com/p/pw3j3pbnPz/
[20:21] <lordcirth> That's all
[20:22] <lordcirth> I've also tried with and without /etc/systemd/network/50-netplan-brup.network: http://paste.ubuntu.com/p/fVNXdgB954/
[20:25] <cyphermox> lordcirth: I guess missing dhcp4: no  dhcp6: no  accept-ra: no for vlan10
[20:27] <lordcirth> cyphermox, no change
[20:28] <cyphermox> ok, then let's look at the files in /run/systemd/network
[20:29] <TheBloke> Hi all. I have an Ubuntu Server system with two 3TB disks. Currently only one disk is in use.  Is it possible to convert this to an LLVM array, without losing data?  The active disk has three partitions (8GB swap, 40 GB for OS, then the remainder for data.)  The second disk is blank (or will be).   Is it possible to activate the second disk as part of a RAID-0 stripe or RAID-1 mirror with the active disk, while preserving the existing
[20:29] <TheBloke>  partitions and data on disk1?
[20:29] <cyphermox> lordcirth: can you send the files to me (cyphermox at ubuntu.com)
[20:30] <lordcirth> cyphermox, does this work? http://paste.ubuntu.com/p/jmHCKwC4xM/
[20:30] <lordcirth> They are fairly short
[20:30] <cyphermox> yeah that works
[20:32] <lordcirth> 'tail -n 100 *' is handy, it puts those headers in automatically
[20:34] <lordcirth> An interesting thing is that if I add the interface to br10 manually, it brings it up automatically, like something was blocking on it
[20:34] <cyphermox> I see nothing wrong with the config
[20:35] <cyphermox> didn't you say earlier than enp0s8 was down initially?
[20:36] <cyphermox> here, assuming you have access to the console and not just remotely, I'd reboot and check what networkd says its state is, whether it is degraded or what, and then the output of 'ip link'
[20:36] <cyphermox> lordcirth: maybe file a bug in Launchpad
[20:37] <lordcirth> Yeah it's a VM on my workstation
[20:38] <lordcirth> networkctl status -a : http://paste.ubuntu.com/p/k37RzBfrRV/
[20:38] <lordcirth> ip link : http://paste.ubuntu.com/p/GwvMtGCC5y/
[20:38] <lordcirth> Anything else?
[20:39] <lordcirth> I'm not even sure where the problem lies, to report it properly
[22:53] <TJ-> lordcirth: I can't compare this locally at present, but in the status output for vlan10 it reports "/run/systemd/network/10-netplan-enp0s8.network" ... I'm wondering if that should be "10-netplan-vlan10.network"
[22:53] <TJ-> lordcirth: what does it show when the interface is up correctly?
[23:05] <blackflow> TJ-: unit filename is not directly related to NIC name (it only matters when overriding through the hierarchy of systemd dirs)
[23:08] <TJ-> blackflow: right, but there is a glitch there so it could be a clue.
[23:09] <blackflow> hrm, possibly yes


[12:46] <WoC> is there a repo for kernel 5.17.x or 5.18.x ?
[12:57] <bittin> there is 5.17 kernels: https://kernel.ubuntu.com/~kernel-ppa/mainline/
[12:57] <bittin> 5.18 is still under development
[13:02] <WoC> right, rc :)
[13:04] <WoC> is there a simple way to add that as a repo ?
[13:22] <oerheks> not, mainline needs to be installed manually
[13:22] <oerheks> !mainline
[13:22] <oerheks> see the howto


[03:19] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.16]
[06:45] <RAOF> Huh!
[06:46] <RAOF> Reviewing linux-firmware for hirsute, the diff at http://launchpadlibrarian.net/551304131/linux-firmware_1.197.2_1.197.3.diff.gz differs from the diff presented by sru-review.
[06:47] <RAOF> Specifically, the sru-review diff drops a bunch of the changes?
[06:47] <RAOF> Anyone else seen that before?
[06:48] <RAOF> (Specifically, it has dropped all the "binary files ..../amdgpu/..." lines, while keeping those lines for the mediatek firmware files)
[06:57] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (hirsute-proposed) [1.197.3]
[08:36] -queuebot:#ubuntu-release- Unapproved: rejected python-magnumclient [source] (focal-proposed) [2.11.0-0ubuntu5]
[08:42] -queuebot:#ubuntu-release- Packageset: Added language-pack-gnome-kab to langpack in focal
[08:42] -queuebot:#ubuntu-release- Packageset: Added language-pack-gnome-kab-base to langpack in focal
[08:42] -queuebot:#ubuntu-release- Packageset: Added language-pack-kab to langpack in focal
[08:42] -queuebot:#ubuntu-release- Packageset: Added language-pack-kab-base to langpack in focal
[08:51] -queuebot:#ubuntu-release- Unapproved: accepted python-magnumclient [source] (focal-proposed) [2.11.0-0ubuntu5]
[08:58] -queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [source] (focal-proposed) [3.36.1-1ubuntu1]
[10:03] <xnox> LocutusOfBorg:  not giving up on RRR:no => suspecting something in dh_strip now https://bugs.launchpad.net/ubuntu/+source/debugedit/+bug/1938886
[10:05] <LocutusOfBorg> xnox, merging src:rpm will make debugedit go in sync with debian...
[10:05] <LocutusOfBorg> maybe we can try that?
[10:06] <LocutusOfBorg> oh no, we removed debugedit from rpm, in our delta :/
[10:07] <LocutusOfBorg> well lets do the merge anyway
[10:29] <xnox> LocutusOfBorg:  i think we use the one from debugedit package, not the one from rpm package?! or vice versa? we have two of them.
[10:30] <doko> LocutusOfBorg, xnox: yes, merge is needed. the next upstream rpm should use the split-out debugedit
[10:31] <doko> RPM 4.17.0 BETA1 released! (Jun 22 2021), so not yet
[10:33] <LocutusOfBorg> ok doko yes merge already done, we got some 3 CVE fixed from debian upload
[10:33] <LocutusOfBorg> but no new rpm release
[10:33] <ginggs> i happened to see debugedit 5.0 was released on 2021-07-26
[10:33] <LocutusOfBorg> looking at the differences between debugedit in rpm and in split out package, nothing so different...
[10:33] <LocutusOfBorg> let see if new release has something interesting
[10:34] <doko> well, the interesting think is the split, so it can be used in non-rpm environments without rpm
[10:34] <LocutusOfBorg> doko, I mean some "hey we accidentally lost SUID bits in previous releases, fixed in 5.0" or similar :)
[10:35] <LocutusOfBorg> can I update debugedit to 5.0^
[10:36] <doko> sure
[10:36] <LocutusOfBorg>     debugedit: check write to list_file succeeds
[10:36] <LocutusOfBorg>
[10:36] <LocutusOfBorg>     We didn't check, or ignored, errors writing to the list_file. Always
[10:36] <LocutusOfBorg>     produce an error if we cannot write to the list_file.
[10:36] <LocutusOfBorg> this is what I need that is in 5.0
[10:36] <LocutusOfBorg> xnox, ^^
[10:37] <LocutusOfBorg> at least the tool now should error out if something fails during chmod
[10:37] <LocutusOfBorg>     debugedit: Report errors if we cannot chmod the file.
[10:37] <LocutusOfBorg>
[10:37] <LocutusOfBorg>             * tools/debugedit.c (main): Check result of chmod and call error
[10:37] <LocutusOfBorg>             if necessary.
[10:39] <LocutusOfBorg> xnox, would you mind doing another test once new debugedit publishes?
[13:12] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (focal-proposed/main) [1:20.04.35 => 1:20.04.36] (core)
[13:12] -queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (hirsute-proposed) [1:3.38.5-1ubuntu2]
[13:14] -queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (focal-proposed) [2.0.0ubuntu<IP_ADDRESS>]
[13:16] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (focal-proposed) [1:20.04.36]
[14:08] <xnox> LocutusOfBorg:  will do!
[14:08] <LocutusOfBorg> should be available in proposed pocket now
[15:14] -queuebot:#ubuntu-release- Unapproved: base-files (focal-proposed/main) [11ubuntu5.3 => 11ubuntu5.4] (core, i386-whitelist)
[15:37] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.26 => 2.664.27] (desktop-core, i386-whitelist)
[15:37] <sil2100> bdmurray: a quick small fix for the iot parts, sorry for missing this earlier! ^
[15:37] <sil2100> Oh wait
[15:37] <sil2100> Will re-upload, wait
[15:38] <sil2100> Ok, next upload will be the one
[15:39] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (focal-proposed) [2.664.27]
[15:40] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.26 => 2.664.27] (desktop-core, i386-whitelist)
[15:41] <sil2100> ^
[15:48] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.27]
[16:01] <xnox> LocutusOfBorg:  still nope! https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1938886
[16:05] <xnox> LocutusOfBorg:  i wonder if it is something more weird, like setuid is not restored cause debugedit failed earlier than that and didn't leave the binary untouched.
[16:53] <LocutusOfBorg> xnox, I blame strip TBH
[17:42] <xnox> LocutusOfBorg:  i blame cat > file!
[17:43] <xnox> LocutusOfBorg:  doko: posted more comments on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1938886 the more i dig into it, the more i hate it. https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1938886
[18:32] <xnox> LocutusOfBorg:  not reproducible in debian, because strip in debian is old which used to preserve permissions.
[18:32] <xnox> LocutusOfBorg:  and the fixes to keep permissions in debhelper are not enough to keep setuid it seems.
[19:07] <coreycb> ubuntu-archive: hello, please can we have python-eventlet removed from impish-proposed? it is blocked with an autopkgtest failure and we've decided to keep gunicorn in sync with debian for now instead of patching it, and the eventlet delta does not pick up too much new.
[19:54] <apw> coreycb, gone.
[19:54] <coreycb> apw: thanks
[21:10] -queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (impish-proposed/universe) [21.10] (personal-fossfreedom, ubuntu-budgie)
[21:46] <vorlon> apw: always happen> it certainly hasn't happened in the past.  have the nvidia ABIs just not been changing until now?
[22:27] <bdmurray> could some archive admin (AA) blacklist boxer-data see bug 1843049
[22:29] <bdmurray> and could that branch not be a +junk one so people could submit MPs?


[06:38] <didrocks> good morning!
[06:50] <k_alam> Please look into following issues....
[06:51] <k_alam> https://bugs.launchpad.net/ubuntu/+source/libgdata/+bug/1698437
[06:51] <k_alam> https://bugs.launchpad.net/ubuntu/+source/policykit-desktop-privileges/+bug/1670269
[06:51] <k_alam> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1690407
[06:53] <k_alam> Nautilus issue is really complicated and probably xorg specific...but mate/cinnamon fixed it by patching caja/nemo
[06:53] <k_alam> Thanks
[07:23] <oSoMoN> good morning desktoppers
[07:23] <duflu> Hello oSoMoN
[07:24] <oSoMoN> hey duflu
[07:26] <duflu> Curiously there's a big reduction in lag using GNOME on Wayland compared to Xorg. Bigger than I expected. Although I'm only assuming both are using hardware cursors
[07:26] <duflu> ^ RAOF did you ever notice that?
[07:28] <RAOF> duflu: As always, “lag” is an unhelpful term :)
[07:28] <duflu> RAOF: Visible disparity between the cursor and titlebar when dragging a window
[07:28] <RAOF> Xorg cursor will be more responsive to mouse movements, wayland cursor will be better synchonised to window movements.
[07:29] <duflu> Is it software rendered or did mutter use the delayed rendering trick (I think Weston already has)?
[07:29] <RAOF> No?
[07:29] <RAOF> Xorg cursor is entirely divorced from frame updates (to the extent that frame updates exist at all in X, which is not very much)
[07:29] <RAOF> Wayland cursor is updated once a frame.
[07:30] <duflu> RAOF: Oh, right, OK.
[07:30] <duflu> Good trick, apparently
[07:30] <RAOF> I think that the SIGIOectomy of Xorg has been done, so cursor updates are performed in a regular thread rather than a signal handler.
[07:31] <duflu> Nevermind. I have a card in the backlog to port mirvanity to Wayland. That would provide better answers
[07:33] <seb128> good morning desktopers
[07:33] <oSoMoN> good morning seb128
[07:33] <duflu> Hi seb128
[07:33] <seb128> hey oSoMoN, duflu, RAOF
[07:34] <didrocks> hey oSoMoN, duflu, RAOF, re seb128
[07:34] <seb128> lut didrocks :-)
[07:35] <seb128> had an ok trip out of the waiting and the suboptimal wifi?
[07:35] <oSoMoN> salut didrocks
[07:35] <Mirv> once duflu is done with that and hopefully someone ports mirvfb somewhere too, I might finally stop getting Mir related highlights :)
[07:35] <oSoMoN> :)
[07:35] <oSoMoN> hey Mirv, how are you doing?
[07:35] <didrocks> seb128: yeah, the trip was uneventful, everything on time as expected and waited a lot with flaky wifi as you saw…
[07:35] <didrocks> but that was ok, back home finally :)
[07:35] <RAOF> Hey yo everybody!
[07:35] <duflu> Mirv: Long time no see. Sorry about that but yeah the name would change...
[07:36] <seb128> didrocks, :-)
[07:36] <didrocks> seb128: also, network, didn't get any (they even didn't gave us the "guest" password) during our workshop…
[07:36] <Mirv> oSoMoN: hey oSoMoN, fine thanks, I've just had a few weeks of work but planning to spend holiday for July as originally planned (before April)
[07:36] <didrocks> hey Mirv!
[07:36] <seb128> :-/
[07:36] <Mirv> duflu: no problem, it always brings smile to me when I get those funny highlights ;)
[07:36] <Mirv> hey didrocks
[07:36] <Mirv> oSoMoN: how are you?
[07:37] <oSoMoN> Mirv, I’m good, thanks! Holidays sound good, I’ll be afk a couple of weeks at the end of July too, looking forward to it :)
[07:38]  * didrocks is eager to see the lightm -> gdm transition so that we can do the iso cleanswap
[07:39] <didrocks> that will remove the indicators, and so, ubiquity after installation and such and such¿
[07:41] <duflu> didrocks: I'm hoping gdm will also work around bug 1700485
[08:01] <Laney> morning!
[08:03] <didrocks> hey Laney
[08:04] <Laney> hey didrocks, wb
[08:04] <Laney> how are you and how was it?
[08:07] <didrocks> I'm good but a little bit tired due to travelling and arriving late yesterday
[08:07] <didrocks> the demo and workshop were well received from what I heard from
[08:09] <seb128> hey Laney, back from London already?
[08:09] <seb128> didrocks, ubiquity is kept because of the indicators?
[08:10] <seb128> didrocks, on the iso cleanswap I put a bunch of items in the trello card, I think there are some things we can get out but I don't think it's going to be big on space or maintaince saving
[08:10] <seb128> well out of what is going to automatically fall out once gdm replaces lightdm
[08:12] <Laney> yes, back last night
[08:12] <Laney> how are you seb128?
[08:12] <seb128> was the day in London good? useful?
[08:13] <seb128> I'm good, I had some 7 hours sleep this night, also it's raining today and fresh which is nice for a change
[08:14] <didrocks> seb128: yep, see the bug report I referenced in the trello card with cyphermox_'s investigation
[08:15] <didrocks> seb128: yeah, I saw your items on the card!
[08:15] <didrocks> we can maybe removed Qt, so it will be quite some size :)
[08:15] <seb128> right, that's probably just a matter of removing checkbox
[08:16] <seb128> or going back to the old gtk version
[08:16] <seb128> somebody pinged jibel about that some time ago but I think he said it was not somebody from qa and to ask $somebodyelse
[08:17] <Laney> seb128: being there for some desktop related discussions was helpful ...
[08:17] <Laney> and meeting up with people
[08:18] <Laney> got to abuse ximion about some bugs
[08:18] <seb128> haha
[08:25] <duflu> koza, willcooke, Are there any bluetooth topics to discuss today? I have none that I can recall
[08:28] <duflu> + seb128
[08:28] <seb128> duflu, I don't have any topic and willcooke is at a snappy sprint so not going to join
[08:29] <seb128> duflu, maybe we should just skip this one if there is nothing to discuss?
[08:29] <duflu> seb128, Depends on koza. Also I'm out for next week's
[08:32] <jibel> I'm stuck. anyone see anything obvious in this list of updates https://launchpadlibrarian.net/325600829/livecd.ubuntu.manifest.diff that could cause bug 1700557 ?
[08:33] <jibel> i'm updating all the packages 1 by 1 but it's tedious
[08:34] <jibel> it looks like a kernel bug the the kernel is the same between the 2 images
[08:34] <koza> duflu, we can skip the meeting
[08:34] <duflu> koza, so long as you don't get surprised by my absence next week too :)
[08:35] <koza> duflu, I promise I will not :)
[08:35] <seb128> jibel, I see nothing suspicious in that list
[08:35] <seb128> is the manifest listing kernels and such?
[08:35] <seb128> duflu, koza, let's skip then?
[08:36] <koza> seb128, duflu, yes let's skip
[08:36] <seb128> k
[08:37] <jibel> seb128, yes, it lists the content of the squashfs
[08:37] <seb128> didrocks, Laney, I wonder if we should start removing the compat_desktop hacks from e.g nautilus as well
[08:37] <jibel> the kernel was <IP_ADDRESS>.24
[08:37] <Laney> seb128: we can do, but those benefit other desktops too
[08:37] <jibel> it ididn't change
[08:38] <Laney> I think if we do then at least the migration from unity favourites to gnome shell favourites should fix that up
[08:38] <Laney> or wait, isn't there a translation table in gnome shell itself?
[08:38] <seb128> Laney, we did change the unity launcher config already afaik
[08:39] <seb128> but the rename was an issue for e.g default mimetype handlers
[08:39] <Laney> how?
[08:39] <seb128> or other desktops
[08:39] <seb128> well, your mimeapps (or whatever the name of that file is called) listed the old name
[08:39] <seb128> and nothing is rewritting it with the new name
[08:39] <seb128> well, if you have an user edited one
[08:39] <seb128> where you changed for example your default image viewer to gimp and then back to eog.desktop
[08:40] <Laney> yeah
[08:40] <Laney> I meant "how?" for the unity launcher thing
[08:40] <seb128> Laney, http://launchpadlibrarian.net/325869839/nautilus_1%3A3.24.1-0ubuntu3_1%3A3.24.1-0ubuntu4.diff.gz
[08:41] <seb128> sorry I'm too lazy to find another url
[08:41] <seb128> but that has the script in the diff :p
[08:41] <Laney> people did that for everything?
[08:42] <seb128> no, I expect some we didn't do
[08:42] <seb128> we did it at least for those in the launcher default config
[08:43] <seb128> anyway that script covers launcher only
[08:43] <seb128> you say that gnome-shell has a mapping table?
[08:43] <seb128> how does it work?
[08:43] <Laney> if it sees one name, that is translated to another
[08:43] <andyrock> good morning
[08:43] <seb128> that covers launcher?
[08:44] <seb128> hey andyrock, how are you?
[08:44] <andyrock> mpt is it possible to have a full design with all the cases?
[08:44] <mpt> andyrock, yes, I’m planning to work on that today
[08:44] <Laney> https://git.gnome.org/browse/gnome-shell/tree/js/ui/appFavorites.js#n10
[08:45] <andyrock> otherwise it's likely I waste one more week
[08:45] <andyrock> hey seb128 good you?
[08:46] <seb128> andyrock, I'm good thanks!
[08:46] <seb128> Laney, shrug, that's a long list, for sure we didn't migrate most of those
[08:46] <Laney> yep
[08:47] <Laney> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1662296
[08:47] <didrocks> let me scrollback (working on the migration script as we skip)
[08:47] <seb128> Laney, imho we should just stop trying to handle the rename and drop the hacks, it might lead to some config issues for upgraders but oh well, those are easy to fix and the hacks have a cost in maintainance and leads to some buggy UIs where items are listed twice
[08:48] <Laney> ok, well I try to propose ways to mitigate the impact, but if you want to say that we accept the issues then just do it
[08:48] <didrocks> yeah, it was only once for nautilus AFAIK
[08:48] <didrocks> I don't think anybody wrote anything for others
[08:49] <seb128> Laney, I can put a card in the backlog and see how it goes/if we have cycles to work on a better solution
[08:49] <seb128> I'm just getting annoyed by the dup items in some UIs
[08:50] <Laney> what's the chance of that?
[08:50] <Laney> I think nobody will, so that is the same as saying that we won't do it, in which case just don't do it
[08:51] <seb128> hum
[08:51] <Laney> it's fair to say that the workaround creates its own issues
[08:51] <Laney> and was never that complete anyway
[08:51] <seb128> my gut feeling is that the impact on users is small annoyances when they have to re-add a launcher icon or reselect a default app
[08:51] <seb128> which is annoying but easy to workaround
[08:52] <Laney> as you wish then
[08:52] <Laney> I don't think it's that hard to migrate stuff over
[08:52] <Laney> but it is work and if nobody's going to do it
[08:52] <seb128> well that's only my opinion, I would welcome some other people stating what they think
[08:52] <Laney> then decide what is more important
[08:53] <seb128> it's not hard but that table from g-s has some 30 items
[08:53] <didrocks> hum, I can't log into the wayland session anymore
[08:53] <seb128> and some of the packages are direct syncs
[08:53] <Laney> doesn't have to be in the individual packages
[08:53] <Laney> it can be in gnome-shell
[08:53] <Laney> or anywhere in fact
[08:53] <seb128> right
[08:54] <Laney> I don't feel that strongly about it any more
[08:54] <Laney> just made a proposal but you're free to go a different way
[08:54] <seb128> didrocks, wdyt?
[08:54] <seb128> Laney, I'm not deciding more than you here :p
[08:55] <didrocks> you know I'm always in favor of smooth user transitions, especially if it's not a lot of work for us
[08:55] <didrocks> the question though is that most of the transitions have already been done, right?
[08:56] <didrocks> how many are missing since the LTS?
[08:56] <didrocks> (as we missed all the others pre-LTS, and it's too late)
[08:56] <seb128> I don't even remember if those renames happened mostly before xenial or after
[08:56] <seb128> let me check
[08:56] <Laney> it's not too late, since we renamed the desktop files
[08:56] <Laney> that was papering over the problem
[08:56] <seb128> right
[08:57] <seb128> we didn't drop the old name
[08:57] <Laney> although that only happened for a few applications
[08:57] <seb128> so non migrated configs still work
[08:57] <Laney> so it was at best quite incomplete :-)
[08:57] <didrocks> ah, we didn't drop old names
[08:57] <Laney> it makes a copy with the old name
[08:57] <didrocks> so, basically, the issue is for non G-S desktop, if we drop them, correct?
[08:57] <didrocks> (as G-S has that map)
[08:57] <Laney> and gnome-shell for mimeapps associations as far as I can tell
[08:57] <didrocks> oh right
[08:58] <didrocks> I would still do it, doesn't sound to be that much work
[08:59] <Laney> I proposed an idea ages ago https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1662296/comments/2
[08:59] <Laney> but actually I would probably just copy the list instead of making each package do it
[09:00] <seb128> right, each package sounds complex
[09:00] <Laney> and maybe we can tell flavours 'you might want to do this' instead of providing some hook mechanism
[09:00] <seb128> let me put a card in the backlog about doing that migration in gnome-shell's package
[09:00] <didrocks> hum, interesting
[09:00] <Laney> that is probably too difficult
[09:00] <didrocks> a little bit of work on session-migrations though, but sounds like a better and more scalable idea
[09:01] <didrocks> copy the list and having new hooks for all is easier, indeed
[09:01] <seb128> didrocks, you mean on session-migrations itself? or just a migration python script to ship in g-s?
[09:01] <didrocks> seb128: well, with the initial proposal from Laney, it involved some work on session-migrations itself
[09:01] <seb128> right
[09:01] <seb128> well, if somebody wants to do that it would be nice
[09:01] <didrocks> but, if we have a list, we can have a package shipping utility functions somewhere in python for instance
[09:01] <didrocks> and having multiple scripts using it
[09:01] <Laney> yeah
[09:02] <didrocks> which is easier IMHO
[09:02] <Laney> just sharing the list is probably good enough
[09:02] <Laney> and have something common do the mimeapps.list bit as that is shared across environments
[09:02] <didrocks> yep
[09:02] <didrocks> where should this python package live in your opinion?
[09:03] <Laney> https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-store.c#L721 there's a bigger one BTW
[09:03] <Laney> hmm, don't know
[09:05] <seb128> didrocks, Laney, I created https://trello.com/c/M3Vc1BDm/172-handle-better-gnome-desktop-renames
[09:06] <didrocks> perfect, thanks seb128!
[09:06] <seb128> yw
[09:06] <Laney> thx!
[09:06] <Laney> good discussion
[09:06] <didrocks> so, basically, we have those utilities "somewhere"
[09:06] <didrocks> if you ship a list with a simple hook, importing that package
[09:06] <didrocks> it will run the migration for mimeapps and G-S launcher
[09:06] <didrocks> (if needed)
[09:07] <didrocks> and we can add as well other desktop in it
[09:07] <seb128> yeah
[09:07] <didrocks> (everytime checking if the schema is there ofc)
[09:07] <Laney> or the desktops can ship it themselves
[09:07] <Laney> and just read this file in in their hooks
[09:07] <seb128> or have our migration script in gnome-shell or ubuntu-session
[09:07] <Laney> or import the same python module
[09:07] <seb128> and other desktops handle their configs/users
[09:07] <didrocks> could do, I'll explore options
[09:07] <seb128> what Laney said basically
[09:07] <seb128> didrocks, thanks
[09:08] <Laney> ♥
[09:13] <popey> didrocks: hello! do you know of any clutter apps which we have successfully snapped?
[09:15] <popey> I'm getting libgl errors, even when using desktop-gtk3, and the opengl plug (among others).
[09:15] <popey> didrocks: http://paste.ubuntu.com/24970892/ is the super simple clutter app we're testing with
[09:17] <popey> didrocks: http://paste.ubuntu.com/24970908/ is what you get when you run that
[10:07] <Laney> http://people.canonical.com/~laney/weird-things/weather.png
[10:07] <Laney> depressing weather ⓒ GNOME MMXVII
[10:09] <tseliot> seb128, Laney, jbicha: I have a patch for gdm (LP: #1697882), how do I proceed? What branch shall I use for the MP?
[10:10] <oSoMoN> didrocks, https://github.com/ubuntu/snapcraft-desktop-helpers/pull/66
[10:28] <mpt> Laney, it’s not just light rain, it’s Light rain
[10:38] <oSoMoN> seb128 (or anyone else who can sponsor): I'm gonna need cppunit 1.14 in artful, filed sync request as bug #1700953
[10:38] <oSoMoN> (needed to build LO 5.4.0 RC1)
[11:23] <Laney> tseliot: I don't know of a branch for gdm3, so a debdiff on the bug is probably OK - and if it's suitable for upstream, please submit it there too & then write the URL into the patch you submit & link the bug. :)
[11:25] <Laney> oSoMoN: looks like it breaks other stuff, what should we do there?
[11:41] <jbicha> tseliot: lp:~ubuntu-desktop/gdm/ubuntu (for artful)
[11:42] <jbicha> good morning
[11:45] <Laney> Vcs-Bzr should say that
[11:45] <Laney> hi
[11:52] <oSoMoN> Laney, not sure, I’ll see if the LO dependency can be relaxed back to 1.13
[11:58] <GunnarHj> jbicha: Good morning! Time to sort out the seed MP?
[11:59] <seb128> oSoMoN, Laney, is that a transition? maybe we just need to deal with it?
[12:00] <jbicha> GunnarHj: I believe we don't want extra gnome-getting-started-docs- pkgs in the live image
[12:01] <GunnarHj> jbicha: Too big? I suspected you'd say that. But gnome-user-docs?
[12:01] <jbicha> jibel: you've done work before on iso image size; do you know if Installed-Size or Download-Size is a reasonable estimate of how much space a pkg will take on the iso?
[12:05] <GunnarHj> jbicha: Isn't it the Download-Size, i.e. the size of the .deb files, which adds to the ISO size?
[12:06] <Laney> seb128: sort of, it requires code changes to packages that aren't all uploaded in debian yet
[12:08] <jibel> jbicha, installed-size is a good approximation
[12:13] <jibel> jbicha, and download size is the exact size of the package
[12:13] <jibel> of the deb
[12:13] <jbicha> GunnarHj: ok, so g-u-docs-de is 3.2 MB and -fr is 1.8 MB, etc.
[12:15] <jbicha> I'm thinking those numbers are kind of high, what do you think?
[12:15] <GunnarHj> jbicha: Right. And if we had let the builders strip it, precisely that size would have been added to language-pack-gnome-XX-base for those languages.
[12:18] <GunnarHj> jbicha: I have no own idea of what's reasonable in this case. But if you read that bug report, the overall idea seems to be that nothing further should be pulled by language-selector for those languages.
[12:21] <jbicha> I get 12 MB by adding up those extra languages for user docs: https://paste.debian.net/973701/
[12:22] <jbicha> which bug report?
[12:23] <GunnarHj> jbicha: Bug #1520278
[12:25] <GunnarHj> jbicha: To give you some perspective of things affecting ISO size: The archive size of fonts-noto-cjk is currently 170 MiB in the daily builds. It was recently increased by 100 MiB, but will soon be reduced by 120 MiB by splitting the package.
[12:36] <jbicha> changing the German dictionaries adds 10 MB https://paste.debian.net/973707/
[12:39] <GunnarHj> jbicha: More than I'd have guessed. But -frami is what's preferred by the German users and what has been pulled by pkg_depends for a few cycles. I really think we should get rid of such inconsistencies.
[12:39] <jbicha> GunnarHj: maybe, but I don't think I can make that decision by myself
[12:40] <jbicha> didrocks: since 1520278 was your bug, do you want to weigh in?
[12:40] <GunnarHj> jbicha: Understood. Who can?
[12:40] <jbicha> GunnarHj: the Desktop Team collectively
[12:43] <GunnarHj> jbicha: I think that the reason for the current delta between the seed and pkg_depends is that things have gradually changed over time. I have adapted pkg_depends, but have been unaware of the implication of the seeds.
[12:44] <jbicha> and the extra getting-started-docs pkgs proposed add 83 MB https://paste.debian.net/973708/
[12:45] <GunnarHj> jbicha: The latter is much. :(
[12:46] <jbicha> but if you're measuring by "able to do offline install with no missing language support" for those languages…
[12:47] <GunnarHj> jbicha: Yeah, in that case we can stop talking about sizes. ;)
[12:48] <seb128> oSoMoN, good job figuring out the libreoffice menu issue
[12:51] <jbicha> Ubuntu GNOME followed Ubuntu's example and installed the extra language suppport in 16.10 (the iso went from ~1.2 GB to ~1.4 GB)
[12:53] <jbicha> but g-getting-started-docs wasn't split out yet (the Ubuntu GNOME daily now says ~1.5 GB)
[12:54] <oSoMoN> seb128, thanks for spotting it!
[12:54] <seb128> yw :-)
[12:57] <GunnarHj> jbicha: Compared with Ubuntu GNOME 16.10/17.04, the ISO size ought to be reduced a bit when packages are moved to main stripped.
[12:58] <GunnarHj> s/main stripped/main and stripped/
[12:59] <jbicha> GunnarHj: if we don't get additional comments here, feel free to ask on the desktop mailing list or at a Tuesday meeting
[13:01] <seb128> cyphermox_, hey, did you see my ping yesterday? what's the status of n-mp/nplan/autopkgtest?
[13:02] <GunnarHj> jbicha: Since it's Wednesday, I think I'll post to the list then.
[13:07] <GunnarHj> seb128: Hi Sebastien, can you please look at bug #1684097? I think that they messed up the POT creation somehow - please see my latest comment. Do you have an idea offhand how to fix it?
[13:07] <seb128> hey GunnarHj
[13:10] <tseliot> Laney, jbicha: ok, thanks
[13:10] <jbicha> seb128: are you ok with the patches at LP: #1696418 and LP: #1575222 ?
[13:11] <seb128> jbicha, the first one no opinion, I think it's wrong to not debug the issue and fix it properly but I don't care enough about trusty to spend time debugging it and I'm not going to block others if they want to workaorund that way
[13:12] <seb128> the other one looks good
[13:16] <mpt> andyrock, if a livepatch fails, the fallback is for it to install as a normal update (requiring restart), right?
[13:16] <andyrock> yeah, so you should update/upgrade restart with the new kernel
[13:17] <andyrock> I don't think there are fixes that are distributed with livepatch but not with normal repo
[13:17] <mpt> andyrock, do you you have any data on how often it happens that a livepatch update doesn’t work?
[13:17] <andyrock> nope
[13:32] <jbicha> k_alam: if you attach a patch to an Ubuntu bug, please remember to subscribe ~ubuntu-sponsors https://wiki.ubuntu.com/SponsorshipProcess
[13:34] <didrocks> jbicha: unsure I want to dive into such a discussion before we get a good idea of our iso size with the transitions done
[13:48] <didrocks> popey: I don't know about any of them, sorry
[13:54] <GunnarHj> jbicha: One thing just struck me: As regards gnome-user-docs-<lang> for the big languages, they would basically replace localized ubuntu-docs pages in the language-pack-gnome-XX-base packages, so the net effect on the ISO size ought to be negligible. Given that, the remaining concern is the German hunspell packages and gnome-getting-started-docs-<lang>. Do you agree?
[13:59] <tseliot> jbicha: ok, merge proposal sent
[14:14] <flexiondotorg> muktupavels Hi
[14:14] <muktupavels> flexiondotorg: hi
[14:15] <flexiondotorg> muktupavels I thought it might be a good idea to introduce you to greyback
[14:15] <Trevinho> Laney: hey, I've noticed there's an u-c-c in proposed for xenial, with a bug that has verification-failed
[14:15] <greyback> muktupavels: hi
[14:15] <muktupavels> ?
[14:15] <muktupavels> greyback: hi
[14:15] <flexiondotorg> muktupavels greyback is the Mir lead. He spoke to me on Monday about how Mir could be used as a Wayland compositor.
[14:16] <Laney> hi Trevinho
[14:16] <Laney> Trevinho: ok?
[14:16] <flexiondotorg> muktupavels Thought you might be interested in hearing about these developments.
[14:16] <Trevinho> Laney: so.. I've to release a change too in xenial, so I'm wondering how long I should wait or... if I can just add the PR to your silo waiting
[14:16] <Trevinho> Laney: yes, ok. You're still in london?
[14:16] <greyback> muktupavels: I'm wanting to chat with shell/window manager devs, to learn what their plans are for Wayland adoption in future
[14:17] <greyback> muktupavels: we've this big chunk of code called Mir, which (once we've Wayland support enabled) might be of use to shell authors, but there's likely features we're missing that you'd need
[14:18] <greyback> muktupavels: if you can spare me a few mins, I'd like to pick your brain on this topic
[14:18] <Laney> Trevinho: I think that verification-failed could be verification-done-xenial. The change works, it just happens to not fix the bug.
[14:19] <muktupavels> greyback: I dont know anything about wayland...
[14:19] <Laney> do you want to push on changing that / getting it released?
[14:20] <muktupavels> flexiondotorg: what are your plans about Metacity in MATE?
[14:21] <Trevinho> Laney: ok, so I'll change that
[14:22] <greyback> muktupavels: budgie uses metacity, right?
[14:22] <Laney> meh, my desktop just crashed in the middle of an upgrade
[14:23] <greyback> muktupavels: talking with flexiondotorg we were just discussing the things that their metacity fork would need, should it move away from X11
[14:23] <muktupavels> greyback, no
[14:23] <muktupavels> they use mutter
[14:23] <didrocks> do you know if G-S can pin devices in the dash?
[14:23] <didrocks> (knowing if it's something I need to transition as well)
[14:23] <greyback> muktupavels: durrr, think I'm getting my wires crossed, sorry
[14:24] <muktupavels> greyback: my opinion is that Metacity has been and will be x11 only
[14:25] <greyback> muktupavels: ok. Metacity does everything you need from a compositor? Any features you wish it had?
[14:27] <greyback> muktupavels: and for budgie-wm, is mutter easy to work with?
[14:27] <muktupavels> greyback: what features? example?
[14:28] <muktupavels> greyback: I dont know
[14:29] <greyback> muktupavels: features I think of are "is it flexible enough for what you want", is the window management good? Does it save/restore your window positions if you plug/unplug external monitors? Is it using your GPU, or software only
[14:30] <greyback> high-dpi support is nice to have. touch screen support too
[14:32] <muktupavels> dont know about window positions when plugin / unplugin monitors. probably not.
[14:33] <muktupavels> Metacity has high-dpi support.
[14:36] <greyback> muktupavels: ok, well it sounds like you're pretty happy with metacity at the moment
[14:37] <greyback> muktupavels: but if you ever fancy looking into moving away from X, look me up, I'll have info you might find useful
[14:38] <muktupavels> greyback: yes, I am happy. there are things that I want, but moving away from x is not one of them.
[14:38] <greyback> muktupavels: ok, well thanks for chatting with me
[14:38] <muktupavels> :)
[14:41] <flexiondotorg> muktupavels The plans for Metacity in MATE are unchanged from what we discussed a few weeks back.
[14:41] <didrocks> Trevinho: do you have the scaling configuration key I need to migrate between unity and G-S?
[14:42] <flexiondotorg> muktupavels We'd like to update mate-settings-daemon so Metacity is fully supported and allow distro maintainers to ship either Metacity or Marco.
[14:42] <Trevinho> didrocks: well, so far we can't migrate anything, just reset the defaults
[14:42] <Trevinho> didrocks: so they're font-scaling-factor and ui-scaling in org.gnome.desktop.interface
[14:42] <Trevinho> didrocks: ah. and the cursor-size one
[14:42] <didrocks> Trevinho: hum, why reset? if we keep the same values, it's going to break?
[14:42] <flexiondotorg> muktupavels The MATE dev who is going to work on the m-s-d changes is taking exams right now, so I expect that work to start in a few weeks.
[14:43] <didrocks> (and so, what to migrate later on as they are in org.gnome.*)
[14:43] <muktupavels> flexiondotorg: OK
[14:43] <Trevinho> didrocks: we can't reuse those with great results in gnome...
[14:43] <Trevinho> didrocks: also that would break the gnome automatic-scaling algo
[14:43] <didrocks> Trevinho: did you change the scale, or is it the float vs integer thing?
[14:44] <Trevinho> didrocks: so, we can migrate the settings later once the new mutter configuration is theree with per-monitor-scaling
[14:44] <Trevinho> but right now it's just not worth it
[14:44] <didrocks> Trevinho: but basically, you are changing the scale/definition of those keys?
[14:44] <didrocks> this is why they are not compatible with the previous values?
[14:44] <Trevinho> didrocks: the new settings will be inside mutter config ~/.config/monitors.xml
[14:44] <Trevinho> but that file has not any room for scaling right now
[14:45] <didrocks> Trevinho: sorry, but I would like to understand why the previous values aren't compatible (probably stupid question, but I didn't dive into your work) :)
[14:45] <Trevinho> didrocks: so, if you just keep thje values we have they'll break things in some cases
[14:46] <didrocks> so, you changed the semantic of the values?
[14:47] <Trevinho> didrocks: currently they are not... But you'll just end up with global values which might be wrong. Like if the user had a 1.5 scaling he'll get a shel and everyhthing scaled at 2 and the text at 0.75
[14:47] <Trevinho> didrocks: this *migtht* be ok for now...
[14:47] <Trevinho> But... the thing is when the new mutter configuration will be used, we'd have to reset these values anyway to rely on user configuration or automatic-scaling.
[14:47] <didrocks> ah, because you are more fine-grained and can scale multiple things
[14:47] <didrocks> ok
[14:47] <didrocks> so
[14:47] <Trevinho> So, up to you, or we do reset them now, or later
[14:48] <didrocks> but we'll need to reset them in any case
[14:48] <didrocks> and not basing on them
[14:48] <didrocks> correct?
[14:48] <Trevinho> yeah, otherwise all the scaling we're doing now, is just bypassed
[14:48] <didrocks> ok
[14:49] <Trevinho> we *migth* reuse the com.ubuntu.user-interface settings in future to figure out user preferences on fractional scaling
[14:49] <mpt> andyrock, design completed. <https://wiki.ubuntu.com/SoftwareUpdates?action=diff&rev2=214&rev1=211> The part I haven’t done is the error cases, because I don’t know what they are.
[14:49] <Trevinho> so we won't loose that information, but right now, I'm not sure what's the best approach
[14:49] <didrocks> Trevinho: I don't find font-scaling-factor
[14:49] <Trevinho> I had to do this, in order to get things working in the new mutter
[14:49] <didrocks> nor ui-scaling
[14:50] <didrocks> only cursor-size
[14:50] <Trevinho> didrocks: names are actually scaling-factor for UI
[14:50] <Trevinho> and text-scaling-factor
[14:51] <didrocks> Trevinho: better with the correct name! Ok, going to reset the 3 at the same time :)
[14:51] <didrocks> thanks!
[14:51] <andyrock> mpt: error cases for what? to enable livepatch  or in the status of livepatch?
[14:51] <didrocks> only if they had Unity, ok?
[14:51] <didrocks> Trevinho: or for everyone upgrading?
[14:51] <mpt> andyrock, both
[14:51] <andyrock> mmm for enabling it can be:
[14:52] <andyrock> 1. we don't get the livepatch token from the service for an user (e.g. the user is not allowed to use the service)
[14:53] <andyrock> 2. we get a token but the user is already using livepatch on more that 3 machines
[14:53] <andyrock> so enable will fail
[14:54] <andyrock> 3. We get a corrupted token and everything will just fail (it should not happen but maybe better to add a generic error case?)
[14:54] <jbicha> Trevinho: it might be better to use a more generic schema name than "com.ubuntu" but I believe GNOME at least doesn't really have code yet to do gsettings>gsettings migration
[14:54] <Trevinho> didrocks: i'd do it only for people with unity
[14:54] <andyrock> mpt: regardint the livepatch status:
[14:54] <Trevinho> jbicha: no wait, it's already there
[14:55] <andyrock> https://www.irccloud.com/pastebin/NZfgrDff/
[14:55] <Trevinho> jbicha: gsettings get com.ubuntu.user-interface scale-factor
[14:55] <andyrock> mpt: let me know if you need something more
[14:56] <jbicha> Trevinho: you're thinking of pushing com.ubuntu.user-interface into GNOME, right?
[14:56] <Trevinho> jbicha: nope... Once we'll have the new mutter configuration working, we *might* use these settings to define the user-defined scaling
[14:57] <didrocks> Trevinho: ok, doing so
[14:57] <jbicha> I don't understand but ok
[14:57] <Trevinho> jbicha: however... Since we'll have sane defaults anyway, i guess we'll just ignore them and user might re-adapt in g-c-c
[14:57] <Trevinho> jbicha: what is not clear?
[14:58] <jbicha> what was not clear was: "will you push the schema into GNOME Shell"? "nope, but we might use it"
[15:02] <jbicha> I think it's fine to reset things (so use different schemas?) and let the user decide if the new way works fine out-of-the-box after upgrade
[15:05] <jbicha> tseliot: is NVIDIA working to get KMS working correctly? do you know when that will be ready?
[15:21] <Trevinho> jbicha: oh, well... the situation is a bit tricky in fact... We should probably have in the past untiy not to set gtk-default settings by default but using a different profile or something like that. But now we've done it.
[15:22] <Trevinho> So... If the user logs in gnome we should reset these values. It might be also worth to split the settings in order to have unity *and* gnome working with different parameters, but thsi is not supported. And I've not looked how we can do it. Maybe just unity-settings-daemon could do by chanigng the xsettings instead of touching the gsettings ones
[15:25] <jbicha> why can't you just use different schema names?
[15:28] <Trevinho> jbicha: we might have done it, but we didn't as we needed a quick solution at the time, and something that applied to gtk settings without doing much
[15:29] <Trevinho> jbicha: so now, we can move to different gsettings schemas, I just need to figure out how to make unity-settings-daemon to feed gtk with the unity scaling settings
[15:31] <jbicha> Trevinho: your hidpi work hasn't been merged into GNOME yet, right?
[15:33] <Trevinho> jbicha: nope
[15:33] <Trevinho> jbicha: but anyways these things are still  relevant now
[15:34] <seb128> hum, what are you trying to resolve there?
[15:34] <seb128> I missed the start of the discussion and the backlog is quite long
[15:34] <seb128> is that what to do about the scaling settings on upgrade?
[15:37] <Trevinho> seb128: yes... and then about having both desktops available, with different options
[15:38] <Trevinho> as unity would break gnome by changing the gtk values
[15:38] <seb128> right
[15:38] <seb128> well it's probably not often that the same user alternate between desktops
[15:39] <Trevinho> seb128: but even if an user tries gnome, then he goes back to unity again for a while... Then say we release the fractional and he wants to go to gnome in the LTS or whatever... at that point there won't be a migration (it has already ran)
[15:39] <Trevinho> so... if you go back and forth you break things
[15:39] <seb128> right
[15:39] <seb128> it's not ideally
[15:39] <seb128> ideal
[15:39] <seb128> but most users don't do back and forth
[15:40] <didrocks> yeah, so, I conditioned the reset to:
[15:40] <Trevinho> yeah, well who does it, generally know how to fix too
[15:40] <didrocks> - you have unity installed
[15:40] <Trevinho> but still
[15:40] <didrocks> - first time you start ubuntu or ubuntu-wayland session
[15:40] <Trevinho> seb128: I've to check this, but I guess maybe using u-s-d to handle the values isn't bad
[15:41] <seb128> didrocks, that seems about right to me
[15:46] <didrocks> hum, no more bzr rewrite/rebase
[15:46] <didrocks> and ken pushed things on gnome-session :p
[15:46]  * didrocks will merge then
[15:46] <Trevinho> didrocks: oh, about that,....
[15:46] <Trevinho> didrocks: I can't get the bzr rewrite plugin to work here
[15:47] <Trevinho> didrocks: how to install that?
[15:47] <didrocks> Trevinho: it's been remove
[15:47] <didrocks> removed*
[15:47] <didrocks> from what I see
[15:47]  * didrocks would really like to have new repo org
[15:47] <Trevinho> eh, in fact I installed from src, but I didn't get it as an avvailable command
[15:47] <kenvandine> didrocks, sorry... i updated the branch to reflect what was in artful :)
[15:48] <didrocks> kenvandine: not your fault! :)
[16:25] <seb128> have a good evening desktopers
[16:25] <oSoMoN> have a good one seb128
[16:26] <didrocks> same to you seb128
[16:28] <kenvandine> good night
[16:29] <tseliot> jbicha: they are going to need the Unix Device Memory Allocator API to land in the kernel before they can fix the problem. This might take a while
[16:35] <tseliot> Laney: I replied. Thanks for reviewing the MP
[17:11] <Laney> tseliot: np!
[17:11] <Laney> goodnight!
[17:40] <immu> can someone tell me of why i cannot log into gnome session?
[17:40] <immu> gnome-wayland session?
[17:41] <gQuigs> immu: Ubuntu version?  LiveCD or install?
[17:41] <gQuigs> oh, and graphics card?
[17:41] <immu> i am on 17.10 builds
[17:42] <immu> i think i am running on intel gpu on built
[17:43] <gQuigs> immu: Live or installed?
[17:46] <immu> installed
[17:46] <immu> i am on hybrid graphics
[17:46] <immu> Intel+Nvidia750
[17:48] <gQuigs> immu: I'd guess it's related to that.. can you try full disabling the nvidia card in the BIOS and see if it works then?
[17:49] <immu> sure
[17:49] <immu> since i am on Alpha build i think i cannot switch to Nvidia GPU yet
[17:51] <immu> i am on Nouveau driver. so its using that
[17:59] <immu> also why is firefox stuck at 50.1.x
[18:06] <gQuigs> yea definitely try switching to intel
[18:07] <gQuigs> dev doesn't get security updates, and firefox is usually released that way,  likely worth making that work.. but that's how it is today
[18:10] <immu> when are things expected to be normal at what stage of the release cycle
[18:12] <kenvandine> immu, firefox 54 is in artful-proposed
[18:13] <kenvandine> not sure why it hasn't migrated to release yet
[18:15] <jbicha> because it doesn't build on architectures we care about but don't care about ;)
[18:16] <kenvandine> jbicha, lol
[18:16] <kenvandine> indeed
[18:18] <gQuigs> right, we've discussed that before :)
[18:20] <immu> but i am currently running on 50.1.0 firefox?
[18:20] <kenvandine> immu, that's what's in artful release yes
[18:20] <kenvandine> 54 is in artful-proposed, you'll get it after someone gets it building for all architectures
[18:20] <immu> okie :)
[18:21] <immu> tomm is alpha1 release date
[18:26] <immu> so what shall we see on release alpha1 date
[18:27] <immu> brb rebooting to kernel 4.11.x
[19:00] <immu> back
[19:02] <jbicha> immu: the development release does not get guaranteed security updates, some security updates get delayed a while
[19:03] <jbicha> but for Firefox, one workaround is to use the firefox-next PPA from the mozillateam; that will get you Firefox Beta instead of the latest stable release
[19:04] <immu> jbicha, i shall wait then will use google chrome for a while